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Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee 
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Foreword 

This Technical Specification (TS) has been produced by ETSI Technical Committee Telecommunications and Internet 
converged Services and Protocols for Advanced Networking (TISPAN). 

The present document defines the TISPAN NGN Release 3 IPTV architecture: Integrated subsystem for IPTV functions 

in NGN. 



Introduction 



The present document provides an architectural framework for the end-to-end Internet Protocol Television (IPTV) 
subsystem within the Next Generation Networks architecture. The IPTV framework is designed for interoperability with 
other NGN service subsystems and components. 

The present document identifies functional entities and reference point, which needs to be exposed from IPTV 
subsystem. 
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Scope 



The present document describes the IPTV functional architecture and functions of an NGN Integrated IPTV system by 
integrating of IPTV functions into the NGN architecture. For example, interactions and information flows between the 
IPTV functional entities and other functional entities will be specified. The specification starts from outlining high-level 
IPTV functional architecture, functional groups and is further developed into the more detailed functional architecture, 
reference points and operational modes. 

The architecture is intended to support requirements defined by the respective ETSI TISPAN requirement 
definitions [1] and allow integration new or existing IPTV solutions (such as those defined by DVB, ATIS IIF, ITU, 
etc.) within the NGN architecture. 

The resulting architecture should, should rely as much as possible on common components and integrates, coexist with 
other TISPAN NGN services. 

The following areas are covered: 

Authentication and authorization. 

Content Protection (including DRM). 

Capability exchange. 

Resource Management. 

Policy Management. 

Charging. 

User Profiles. 

The architecture focuses on closer integration between IPTV services and NGN networks, migration scenarios from 
existing solutions (i.e. DVB-IPI, ATIS-IIF) into NGN and common components. 



2 References 

References are either specific (identified by date of publication and/or edition number or version number) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• Non-specific reference may be made only to a complete document or a part thereof and only in the following 
cases: 

if it is accepted that it will be possible to use all future changes of the referenced document for the 
purposes of the referring document; 

for informative references. 

Referenced documents which are not found to be publicly available in the expected location might be found at 
http://docbox.etsi.org/Reference . 

NOTE: While any hyperlinks included in this clause were valid at the time of publication ETSI cannot guarantee 
their long term validity. 
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2.1 Normative references 

The following referenced documents are indispensable for the application of the present document. For dated 
references, only the edition cited applies. For non-specific references, the latest edition of the referenced document 
(including any amendments) applies. 

[I] ETSI TS 181 016 (Release 3): "Telecommunications and Internet converged Services and 
Protocols for Advanced Networking (TISPAN); Service Layer Requirements to integrate NGN 
services and IPTV". 

[2] ETSI TS 102 034: "Digital Video Broadcasting (DVB); Transport of MPEG-2 TS Based DVB 

Services over IP Based Networks". 

[3] ETSI TS 122 240: "Universal Mobile Telecommunications System (UMTS); Service requirements 

for 3GPP Generic User Profile (GUP); Stage 1 (3GPP TS 22.240)". 

[4] ETSI TS 123 240: "Universal Mobile Telecommunications System (UMTS); 3GPP Generic User 

Profile (GUP) requirements; Architecture (Stage 2) (3GPP TS 23.240)". 

[5] ETSI ES 282 001 (Release 2): "Telecommunications and Internet converged Services and 

Protocols for Advanced Networking (TISPAN); NGN Functional Architecture ". 

[6] ETSI TS 182 027 (Release 3): "Telecommunications and Internet converged Services and 

Protocols for Advanced Networking (TISPAN); IPTV Architecture; IPTV functions supported by 
the IMS subsystem" . 

[7] IETF RFC 2782: "A DNS RR for specifying the location of services (DNS SRV)". 

[8] ETSI ES 282 007 (Release 2): "Telecommunications and Internet converged Services and 

Protocols for Advanced Networking (TISPAN); IP Multimedia Subsystem (IMS); Functional 
architecture". 

[9] ETSI ES 282 004 (Release 2): "Telecommunications and Internet converged Services and 

Protocols for Advanced Networking (TISPAN); NGN Functional Architecture; Network 
Attachment Sub-System (NASS)". 

[10] ETSI ES 282 003 (Release 2): "Telecommunications and Internet converged Services and 

Protocols for Advanced Networking (TISPAN); Resource and Admission Control Sub-system 
(RACS); Functional Architecture". 

[II] ETSI TS 187 003 (Release 2): "Telecommunications and Internet converged Services and 
Protocols for Advanced Networking (TISPAN); NGN Security; Security Architecture". 

[12] ETSI ES 282 010 (Release 2): "Telecommunications and Internet converged Services and 

Protocols for Advanced Networking (TISPAN); Charging [Endorsement of 3GPP TS 32.240 
V6.3.0, 3GPP TS 32.260 v6.3.0, 3GPP TS 32.297 v6.1.0, 3GPP TS 32.298 v6.1.0 and 
3GPP TS 32.299 v6.4.0 modified]". 

[13] ETSI TS 132 240: "Digital cellular telecommunications system (Phase 2+); Universal Mobile 

Telecommunications System (UMTS); Telecommunication management; Charging management; 
Charging architecture and principles (3GPP TS 32.240)". 

[14] ETSI TS 183 064 (Release 2): "Telecommunications and Internet Converged Services and 

Protocols for Advanced Networking (TISPAN); Dedicated IPTV subsystem: stage 3 
specification" . 
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2.2 Informative references 

The following referenced documents are not essential to the use of the present document but they assist the user with 
regard to a particular subject area. For non-specific references, the latest version of the referenced document (including 
any amendments) applies. 

[i.l] "An application-level QoS comparison of inter-destination synchronization schemes for 

continuous media multicasting", Toshiro Nunome; Shuji Tasaka, lEICE transactions on 
communications, ISSN 0916-8516, Vol. 87 (2004), No. 10, pp. 3057-3067 (11). 

[i.2] ETSI ES 204 915 (all parts): "Open Service Access (OS A); Application Programming Interface 

(API) (Parlay 6)". 

[i.3] ETSI ES 202 504 (all parts): " Open Service Access (OSA); Parlay X Web Services; (Parlay 

X3)". 

[i.4] ETSI TR 187 013: "Telecommunications and Internet Converged Services and Protocols for 

Advanced Networking (TISPAN); Feasibility study on IPTV security architecture". 

[i.5] SCTE-130 part 1: "Digital Program Insertion - Advertising Systems Interfaces; Part 1 Advertising 

Systems Overview". 

[i.6] SCTE-130 part 2: "Digital Program Insertion - Advertising Systems Interfaces; Part 2: Core Data 

Elements". 

[i.7] SCTE-130 part 3: "Digital Program Insertion - Advertising Systems Interfaces; Part 3: Ad 

Management Service (ADM) Interface". 

[i.8] SCTE-35: "Digital Program Insertion Cueing Message for Cable". 

[i.9] ETSI TS 182 028 (V2.0.0): "Telecommunications and Internet converged Services and Protocols 

for Advanced Networking (TISPAN); IPTV Architecture; Dedicated subsystem for IPTV 
functions". 

[i.lO] ITU-T Recommendation Y.1910: "IPTV functional architecture". 



3 Definitions and abbreviations 

3.1 Definitions 

For the purposes of the present document, the following terms and definitions apply: 

IPTV content identifier: super class of the identifiers that identify content in specific IPTV services 

media stream identifier: identifier carried in a unicast or multicast media stream that identifies that specific media 
stream 

3.2 Abbreviations 

For the purposes of the present document, the following abbreviations apply: 

ADM Ad Management Service 

ADS Ad Decision Service 

A-RACF Access Resource And Admission Control Function 

AS Application Server 

ASF Application Server Function 

BC Broadcast 

BCG Broadcast Content Guide 

BPG Broadcast Program Guide 

BTV Broadcast TV 
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CA Conditional Access 

CDR Content Data Records 

CF Customer Facing 

CFIA Customer Facing IPTV Application 

CIS Content Information Service 

CM Content Marking 

CoD Content on Demand 

CR Content Recommendation 

CRS Content and Service Recommendation Service 

CSCF Call Setup Control Function 

CSP Content and Service Protection 

DHCP Dynamic Host Configuration Protocol 

DNG Delivery Network Gateway 

DNS Domain Name Server 

DRM Digital Rights Management 

EPG Electronic Program Guide 

FE Functional Entity 

GUP Generic User Profile 

HD High Definition 

ID IDentification 

IMS IP Multimedia Subsystem 

IP Internet Protocol 

IPTV IP Television 

IPTVC IPTV Control 

lUDF IP User Data Function 

MCE Media Control Function 

MDF Media Delivery Function 

ME Media Function 

MSAS Media Synchronization Application Server 

NASS Network Attachment Subsystem 

NAT Network Address Translation 

nCoD Near CoD 

NGN Next Generation Network 

NPT Normal Playout Time 

nPVR networked Personal Video Recorder 

PCh Personalized Channel 

pCoD Push CoD 

PES PSTN/ISDN Emulation Subsystem 

POIS Placement Opportunity Information Service 

PPV Pay Per View 

PSS Packet-switched Streaming Service 

PVR Personal Video Recorder 

QOE Quality of Experience 

QoS Quality of Service 

RACS Resource and Admission Control Subsystem 

RTCP Real Time Control Protocol 

RTP Real Time Protocol 

SC Synchronization Client 

SCE Service Control Function 

SCP Service & Content Protection 

SCS Service Capability Server 

S-CSCE Serving CSCF 

SCTE Society of Cable Telecommunications Engineers 

SD Standard Definition 

SD&S Service Discovery and Selection 

SDF Service Discovery Function 

SIS Subscriber Information Service 

SKMF Service Key Management Elementary Functions 

SME Service Membership Elementary Functions 

SP Service Provider 

SPD Service Provider Discovery 

SPE Service Protection Elementary Functions 
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SRV Service Record 

SSF Service Selection Function 

TAI Targeted Advertising 

TPF Transport Processing Function 

iTV Interactive TV 

UCG User Created Content 

UDAF User Data Access Function 

UDF User Data Function 

UE User Equipment 

UGC User Generated Content 

UPSF User Profile Server Function 

URL Uniform Resource Locator 

XDMS XML Document Management Server 



NGN I PTV subsystem 



This clause outlines architectural approach adopted in the present document. The approach is then applied to introduce 
high level IPTV architecture and functional groups in NGN architecture. 

4.1 Concept and Architectural Approach 

The document focuses on defining flexible functional architecture, which can: 

• allow development of new IPTV subsystem in NGN; 

• integrate existing IPTV subsystem in NGN; 

• extend both to support other NGN services; 

as defined in the service level requirements [1]. 

The support for other NGN services has a wide meaning, e.g. the functional architecture would allow coupling 
functionality of IPTV subsystem with functionality of PES or IMS subsystem, which in-turn may support some IPTV 
features as defined in [6] . 

In order to achieve high level of flexibility, the work is focused on identifying and standardizing functional entities and 
reference points, which needs to be exposed from IPTV subsystem to the rest of NGN. Internal IPTV functional entities 
and reference points are identified and described for the completeness of the end to end architecture without intend to 
standardize them. 

The architectural approach considers IPTV subsystem as a functional area, which is integrated into NGN via 
standardized reference points and delivers service level requirements, while allowing internal flexibility and extensions 
for new service types. 

The IPTV integrated subsystem is based upon IPTV domains defined in TS 181 016 [1], clause 4.1 IPTV Roles. 

4.2 High Level Architecture Overview 

Figure 1 presents high-level NGN IPTV functional overview and location of IPTV capabilities in the TISPAN NGN. 
The high level overview illustrates principal functional groups for NGN IPTV services. The functional groups map to 
IPTV roles as defined in clause 4.3. 

The functional groups are used to derive more detailed functional architecture, however, allocation of functions across 
operational and organizational boundaries will vary between implementations. 
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Figure 1 : High-level NGN based IPTV functional architecture 



4.3 Functional groups 



In the context of the present document functional groups are used to describe several functional entities grouped 
together according to some condition, e.g. location in the certain functional layer. 

4.3.1 Application Functions 

Within the present document, the term "Application Functions" includes IPTV and NGN Application Functions. 

NGN Applications: provides the user with rich multimedia applications distributed across multiple NGN subsystems. 
For example, session follow up or messaging exchange between fixed and mobile terminals, presentation of incoming 
calls and phone list management on TV, IPTV or gaming applications based on user presence. NGN applications also 
provide operators with centralized NGN management interface to multiple subsystems for content management, 
charging, interactions with IMS services, others. NGN applications may include application functions used across 
multiple service domains for applications interactions, e.g. IMS and IPTV interactions. NGN applications may include 
service mediation and coordination functionality. 

IPTV Applications: customer facing and operator facing. 

Customer facing IPTV applications provides the server side functions to enable customer facing IPTV applications, 
expose IPTV services to other NGN application and manage IPTV subsystem. Customer facing IPTV applications 
provide service provisioning, selection and authorization of IPTV services. 

Operator facing IPTV applications provide operator control over IPTV subsystem in NGN, content preparation and 
media management, content licensing, subscriber management, offer creation, user profiles. 

Server side IPTV applications expose IPTV services to NGN. 

4.3.2 IPTV Service Control and Media Delivery Functions 

Enables operation of IPTV services in NGN. The key functionality of this layer is to provide, but not limited to, media 
distribution, selection and allocation of media delivery units, IPTV session control and management, interactions with 
other NGN components for admission control and resource allocation, as well as collecting charging and QoS 
information. 

4.3.3 Transport Functions 

Transport Control Functions: contains common NGN components RACS and NASS, provides policy control, 
resource reservation and admission control as well as IP address provisioning, network level user authentication and 
access network configuration as defined in TISPAN. Transport layer definition includes definition from [5]. 
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Transport Processing Functions: the Transport Process Functions represents network access links and IP core. The IP 
core is in charge of data transmission with quahty of service support. 

4.3.4 End User Functions 

Customer transport: provides connection to one or multiple access networks and one or multiple home network 
segments. 

UE: provides user interactions and control over delivery of IPTV and other NGN services. IPTV terminal processes 
serviced multimedia and presents it in user acceptable format. User interactions may include service discovery, 
selection and authorization. Multimedia processing may include requesting multimedia asset in supported encoded 
format, decoding and presenting it to the user in acceptable format, trick mode operators, channel change. 

4.3.5 Management Functions 

The IPTV Management Functions include: 

Service Fulfilment: the functions required to fulfil the IPTV service to the End-User. 

Service Assurance: the functions required to assure the IPTV service provided to the End-User. 

Service Billing: the functions required to ensure proper billing to the end user of delivered IPTV services. 

4.3.6 Content Provider Functions 

The functions provided by the entity that owns or is licensed to sell content or content assets. These are normally the 
sourcing of content, metadata and usage rights. 

4.4 IPTV services 

NGN integrated IPTV supports the following IPTV services [1]: 

Broadcast TV (with or without trick modes). 

Content on Demand (CoD). 

Personal Video Recording (cPVR, nPVR). 

Pay Per View (PPV). 

Interactive TV (iTV). 

near CoD (nCoD). 

push CoD (pCoD). 

User Generated Content (UGC). 

Profiling and personalization. 

Content Recommendations (CR). 

Advertising (Ad) and Targeted Advertising (TAI). 

Messaging services. 

Notification services. 

Personalized channel. 

Bookmarks or Content Marking (CM). 
Table 1 A provides list of services and feature supported by NGN integrated architecture. 
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Table 1 A: IPTV services and features supported by NGN integrated IPTV subsystem 



NGN IPTV Release 
Service & Feature 


TISPAN R2 
NGN dedicated IPTV subsystem 


TISPAN R3 
NGN integrated IPTV subsystem 


Specification 


TS182 028R2[i.9] 


Present document 


Linear/ Broadcast TV 


M 


M 


Linear/ Broadcast TV with Trick Play 


M 


M 


Time Shifted TV 








Content on Demand 


M 


M 


Push CoD 


M 


M 


Near COD 


M 


M 


Network PVR 


M 


M 


Client PVR 


NA 





Audio 


M 


M 


Pay-Per-View 


M 


M 


Interactive TV 


M 


M 


Service discovery 


M 


M 


Service Information (EPG) 


M 


M 


Parental Control 


M 


M 


User Profiling & personalization 








Communications and Messaging 








Notifications 








IPTV Presence 








Interaction between users 








Interaction with NGN services 








Advertising 


M 


M 


Targeted Advertising 


NA 





User Generated Content 


NA 





Internationalization 








Content recommendation 


NA 





Games 


NA 





Picture 


NA 





Bookmarks (Content Marking) 


NA 





Personalized channel 


NA 





Personalized Service Composition 


NA 





Service Portability 


NA 





Service Continuation between IPTV UEs 


NA 





Service Continuation fixed-mobile 


NA 





Remote Control of IPTV services 


NA 





Emergency Information 


NA 





Interaction with 3''^ Party application 
(e.g. Parlay) 


NA 





Interaction with Internet Services 


NA 





Service synchronization 


NA 





Incoming call management 








NOTE: M - Mandatory, 0- Optional, NA - not available or not specified (out of scope in release) in architecture. 





5 NGN Integrated IPTV subsystem functional 

architecture 

The context of the IPTV architecture is represented "end to end" for completeness, starting from the UE on the left to 
the management functions and content providers functions on the right. However, the functions on the right 
(e.g. management and content provider) are outside this release of the specification. 

Integrated NGN IPTV functional architecture is presented in figure 2. 
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Figure 2: NGN IPTV functional architecture 

The figure also includes reference points using dotted lines, which are shown for completeness and outside the present 
document: examples are provided in informative annex showing how such reference points can be used. The two 
reference point outside the scope of the present document shown for completeness are NGN & Customer facing IPTV 
application interactions and Configuration and Authentication. 

The focus of the current specification in on the functions in the middle, namely IPTV functions in the service layer and 
in the transport layer for integration into NGN. 

The functions performed by the service layer are grouped into two levels: 

• the application functions for provisioning an IPTV service consumption by a given user (e.g. service 
selection, where "selection" is used in a wide sense, e.g. including the parental control rules, others); 

• the IPTV service control and delivery functions for the execution of a given instance of an IPTV service 
during service consumption (e.g. the user can experience and control the delivery of a given media content) 
and for the selection of Media Control Function and media delivery during the IPTV service establishment. 

The functions performed in the transport layer apply the principles of TISPAN NGN networks transport layer 
(see definition in [5]) to enable policy control, resource reservation, admission control, IP address provisioning, network 
level user authentication. The relationship between media management, media distribution and media preparation 
functions are presented for the completeness. However, interface definitions are outside the scope of the current release, 
which is represented by the dotted lines. 
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5.1 Functional entities 

The functional groups presented on figure 1 contain the following functional entities used to deliver NGN IPTV 
services. 

5.1.1 Core IPTV functions 

NGN Application FE: application providing functionality across single or multiple subsystem, e.g. messaging 
exchange between fixed and mobile terminals, presentation of incoming calls and phone list management on TV, IPTV 
gaming applications based on user presence, NGN applications may include service mediation and coordination 
capabilities. 

NGN Integrated IPTV supports two approached to user data location: federated and consolidated, as discussed in details 
in clause 9.2. 

In the federated approach user data is located close to application in the following functional entities: 

• NGN Apphcation User Data FE (NGN App UDF): NGN App user data function is responsible for handling 
NGN application and user data. NGN App UDF allows integration of application data across NGN 
applications either using 3GPP data federalization (see [3] and [4]), or known NGN application, e.g. UPSF, or 
other legacy solution. 

• IPTV User Data FE (lUDF): IPTV user data function. IPTV user data function is responsible for handling 
dedicated IPTV user data. lUDF allows integration of user data from IPTV subsystem into NGN either using 
3GPP data federalization (see [3] and [4]), or known NGN application, e.g. UPSF, or other legacy solution. 

To access user data the following functional entity is used: 

• NGN User Data Access FE (NGN UDAF): The NGN UDAF knows the location and gives access to user 
data. An instance of it can be either GUP server if data federalization approach is selected, known NGN 
application, or other legacy solutions. 

In the consolidated approach user data is located and accessed via NGN UDAF, which is: 

• User Profile Server FE (UPSF): The User Profile Server Function (UPSF), as defined in ES 282 001 [5], is 
responsible for hosting a set of user related information, amongst service-level user identification, numbering 
and addressing information, service-level user security information: access control information for 
authentication and authorization, service-level user location information at inter-system level, service-level 
user profile information. 

Customer Facing IPTV Application FE (CFIA): provides IPTV service provisioning, selection and authorization: 

Provide IPTV services offer. 

Enable navigation and selection. 

Verify access right according to the IPTV user profile, e.g. stored in the UPSF. 

Provides authentication and authorization to validate the user's right based on the user profile. 

Authorizes the UE to access the IPTV Service Control and Delivery Functions. 

Provides to the UE initial entry point to the selected service. 

May provide to the UE information on selected IPTV service (e.g. duration, range, etc.). 

May access to the NASS in order to request the geographical user localization. For example, to deliver SD&S 
metadata according to the localization of the user, support user nomadism. 

May provide application usage control like COD credit, COD already purchase with last play range. 

Service Discovery and Selection (SD&S): provides description information for discovery of the service list for Live 
TV and selection of these services or on-demand IPTV services. Particular implementation is outside the scope of the 
present document, e.g. defined in [2] can be used. 
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IPTV Control FE (IPTV-C): 



• Checks if UE has been authorized by the Customer Facing IPTV AppHcation to use IPTV Service Control and 
DeHvery Functions. 

• Provides selection of the Media Control Function during the IPTV service selection ( optional in case of one to 
one relationship between IPTV Control entity and Media Control Function entity): 

Based on location of the Media Control Function (MCF) entity. 

Based on load of the Media Control Function (MCF) entity. 

Based on distribution of contents among media delivery entity. 

Optionally based on resource admission control between UE and media delivery entity. 

• May retrieve in NASS the geographical user localization, to select the Media Control Function entity. 
Media Control Function (MCF): 

• Handling media flow control of MDF (not applicable for multicast e.g. Linear TV). 

• Monitoring the status of MDF. 

• Managing interaction with the UE (e.g. trick mode commands). 

• Handling interaction with the IPTV control function. 

• Keeping an accurate view on status and content distribution related to the different MDFs that it controls. 

• Selecting an MDF, in the case an MCF controls multiple MDFs different criteria, may be applicable as for 
example as follows: 

Load balancing of media delivery entities (MDF). 

Based on distribution of contents among media delivery entities. 

Optionally location of the UE (may need to access NASS in order to request the geographical user 
localization, e.g. to select the Media Delivery entity according to the localization of the user and to select 
nearest MDF). 

Optionally based on resource admission control between UE and media delivery entity or availability of 
content/resources in MDF itself. 

May check user authorization to use requested IPTV service. 

May generate charging information, e.g. for end-user charging based on the viewed content. 

May manage the media processing of MDF. 

Controlling advertisement insertion of MDF, e.g. instructing MDF to play the advert, handling synchronization 
between the advert and IPTV content and synchronization with delay or drift in broadcast TV schedules. 

Providing a direct relationship on the media delivery and media control levels between downstreaming and 
upstreaming UGC sessions for live UGC consumption. 

In IPTV integrated subsystem MCF acts as UE point of contact for requested delivery of the selected IPTV service. 

Media Delivery Function (MDF): 

• Handling media flow delivery (delivering multimedia services to the user). 

• Status reporting to MCF (e.g. reporting on established IPTV media session). 

• Storing of media (e.g. CoD assets), may store some service information with media for IPTV services. 
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• In particular, may be used for storing the most frequently accessed content or user specific content 

(e.g. recording PVR, Time Shifted TV, Pause TV, user generated content) if the same tasks are not performed 
byUE. 

• May additionally process, encode or transcode (if required) media to different required media formats (e.g. TV 
resolution depending on terminals capabilities or user preferences). 

• May perform content protection functionalities (e.g. content encryption). 

• May support content ingestion of IPTV media. 

• May receive media content from UE, e.g. via upstreaming/upload. 

• Handling content download to UE (download CoD content to UE or record BC live stream and subsequently 
download to UE). 

• Performing advert insertion during IPTV content playback, i.e. deliver advert content to the UE during the 
advert insertion opportunity. 

■ May support alternative streams for use with an existing broadcast channel or CoD item, e.g. alternative video, 
audio or subtitle tracks for personalized stream composition. 

For BC services MDF may act as source for multicast streams of BC media streams. 

5.1 .2 Supporting IPTV functions 

Media Preparation FE: a group of functions for manipulating, "preparing', content to enable content delivery to the 
UE. Examples of content preparation are encryption, encoding, keys and access rights generation. Such processes may 
be executed off-line, being considered as belonging to media content management, or on-line, in real-time, then being 
part of the IPTV applications or service delivery and control, e.g. DRM processing may be delegated. 

Service & Content Protection functions (SCP): e.g. Digital Rights Management (DRM) Function and/or Conditional 
Access (CA), implements encryption and/or conditional access for instances of multimedia service delivery. Content 
security elementary functions are defined in clause 7. 

NOTE 1: NGN dedicated IPTV Release 2 refers to SCP as Digital Rights Management (DRM) function. 

NOTE 2: SCP may contain more detailed service and content protection elementary functions and used during UE 
service initiation or service attachment (more detail are in TR 187 013 [i.4]). 

Media Acquisition Function: belongs to the media preparation functions. Implements media acquisition functionality 
acquiring the media content from the content providers, may acquire license rights from the content providers to enable 
media distribution to delivery functions. Media acquisition function can be co-located with media delivery function, 
e.g. for acquisition of live media streams. 

Media Distribution FE: implements media distribution functionality, e.g. physical distribution of multimedia assets 
from centralized location to distributed delivery grid via protocols or life access to broadcast channels. 

NOTE 3: There are relationships and interfaces between Media preparation FE, Media distribution FE, MCF/MDF 
functional elements and content management may be used to purpose manage content ingest as described 
in management clause 8. 

Charging and Accounting Functions: manage customer charging and service subscriptions. 

IPTV Subscriber Management FE: manages IPTV subscriber database. 

5.1 .3 Transport functions 

RACS: TISPAN resource admission and control subsystem. 
NASS: TISPAN network attachment subsystem. 
Transport Processing Functions: as defined in clause 4.3. 
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5.1 .4 Customer Transport functions 



Delivery Network Gateway (DNG): device that is connected to one or multiple access networks and one or multiple 
home network segments. User equipment function: provides user interactions and control over delivery of IPTV and 
other NGN services. May include the following elementary functions: 

• Broadcast-Client Function. 

• On-Demand Client Function - provide interfaces with on demand headend components and enable end user 
application. 

• AudioA^ideo Decoder Function. 

• AudioA^ideo Decryption Function. 

• Optional support for sub-title function. 



5.2 Reference points 



This clause describes reference points for NGN integrated IPTV architecture as shown on figure 2. 
Reference points between the core IPTV functional entities is summarized in table 1 . 

Table 1 : Reference points between core IPTV functional entities 
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NOTE: As discussed in clause 5, IPTV functional architecture includes reference points, which are shown for 

completeness, but are outside the scope for the current release. The considerations for deferring assigning 
reference points to such interfaces are: 

■ functional interactions on the reference points is not used in the current procedures; 

■ reference points are optional; 

■ reference points are left for further study. 

5.2.1 Tr - 1 PTV transactional 

Reference point between UE and Application Functions: 

• Used for UE Authentication and Authorization during initialization. 
NOTE: UE authentication may also be done directly via e2 reference point. 

• Used for user Authentication and Authorization for IPTV service during initialization. 

• Used to provide UE with one or more service offers. 

• Used to enable navigation and service selection. 
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• May instantiate IPTV/converged service offers. 

• Can give access to personalized offers from multiple service domains based upon user profile. 

• Provides to the UE an initial entry point into the IPTV service level subsystem. 

• Provides to the UE information on selected IPTV service. 

5.2.2 Ct2 - UE facing IPTV control 

Optional reference point between UE and IPTV Control: 

• Acts as initial UE point of contact to request delivery of the selected IPTV service. 

• Returns nominated service (media) delivery control function. 

• Provides enough information for IPTV Control to check that UE has been authorized (by the Customer Facing 
IPTV Application) to access the requested resources. 

NOTE: "Optional reference point" refers to a reference point only required in some of the operational modes: 
proxy, redirect, coupled or decoupled as defined in clause 6. 

5.2.3 Sa - IPTV control and Media Control Function 

Reference point between IPTV control and Media Control Function: 

• Used to interact with the Media Control Function (MCE) entity of the IPTV service selected by a user 
(e.g. provides information to the MCE that the user is authorized to access the selected IPTV service). 

• Used to notify the IPTV control with information related to the service selected (e.g. the IPTV service cannot 
deliver the service because of network reasons such as insufficient bandwidth or no media delivery available). 

NOTE: This interface is not used to make the media delivery (MDF) selection; this is the role of the MCE. 

5.2.4 Ss - Service selection 

Optional Ss - Service selection reference point between Customer facing IPTV applications and IPTV control: 

• Used to notify the IPTV control entity of the IPTV service selected by the user. 

• Used to notify the Customer Facing IPTV Application the UE initial entry point to the selected service (Media 
Control Function). 

• Used to notify to the Customer facing IPTV Application with information related to the service selected 
(e.g. the IPTV service cannot be delivered because of network reasons - information from the Sa reference 
point). 

5.2.5 Xc - UE and IPTV Media Control Function 

Xc reference point (media control) - logical end-to-end reference point between the UE and the IPTV Media Control 
Function (MCE): 

• used to exchange media control messages for controlling of the delivery IPTV Media flows. 

NOTE: Transport related reference points are used to carry media control messages over underlying transport 
segment (defined in ES 282 001 [5] and as shown below in figure 3). Depending on the location of the 
MCE, Xc is decomposed into: the Dj reference point between the UE and the access network, optionally 
the Di reference point between the access network and the core network, and optionally the Ds or Iz 
reference point between the core network and the Media Control Function, if the MCE is located behind 
the Core Network. 
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Figure 3: Decomposition of the Xc reference point when the MCF is after the Core Network 

5.2.6 Xp - IPTV Media Control Function and IPTV Media Delivery 
Function 

• Reference point between Media Control Function (MCF) and Media Delivery Function (MDF): used to control 
media delivery sessions in order to support setup of a media delivery session. The media content can be 
distributed among one and more media delivery functions. 

NOTE: If authorization of the user access to the selected IPTV service is still valid, may be used for transmission 
of adaptations to session control and/or media control to the previously selected/established media 
delivery session. 

5.2.7 Xd - UE and IPTV Media Delivery Function 

Xd reference point (media delivery) - logical end-to-end reference point between UE and IPTV Media Delivery 
Function (MDF): 

• carries IPTV media data by appropriate means to the UE (delivers content streams). 

NOTE: Transport related reference points are used to carry media delivery data over underlying transport 

segment (defined in ES 282 001 [5] and as shown in figure 4). Depending on the location of the MDF, Xc 
can be decomposed into: the Dj reference point between the UE and the access network, optionally the Di 
reference point between the access network and the core network, and optionally the Ds or Iz reference 
point between the core network and the Media Delivery Function if the MDF is located after the Core 
Network. 
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Figure 4: Decomposition of the Xd reference point 

5.2.8 e2 - MASS access 

The e2 reference point is defined in ES 282 007 [8] and ES 282 004 [9]. 

5.2.9 e4 - MASS and RAGS 

The e4 reference point is defined in ES 282 003 [10] and ES 282 004 [9]. 
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5.2.10 Gq'-RACS 

5.2.1 1 Ud - access to IPTV user data 

In the federated approach: 

• Used by IPTV application server functions, IPTV subscriber management to access subset of IPTV profiles, 
which are hosted in lUDF. 

In the consohdated approach: 

• User Data implements UPSF functionality. 

• Used to access user data located in User Data function. The Reference point is between IPTV applications 
layer ions and UPSF [5]: As an application server function may choose to use the repository function of the 
UPSF for hosting service-level user data, as transparent data, the interface should comply with Sh reference 
point used between this AS Function and UPSF. 

• The use of Sh reference point conforms to ES 282 007 [8]. 

• The IPTV applications represented on Figure 2, that may use the UPSF repository function are: Customer 
Facing IPTV Applications, IPTV control, IPTV subscriber management. 

5.2.12 Ug - access to NGN user data 

In the federated approach: 

• Used by IPTV applications to provision and access federalized data from service level subsystems, e.g. IMS, 
NGN App UDF, mobile, other profile and non-NGN user data. 

• Used by converged applications (e.g. communicational features on TV, mobile session handover) to provision 
and access federalized data from service level subsystems (e.g. IMS, IPTV UDF, mobile, other profile data 
and non-NGN user data. 

• Provides common access among application to profile data models and data components that are common 
across applications. 

In the consohdated approach: 

• User Data implements UPSF functionality. 

• Used to access user data located in User Data function. The Reference point is to access common user data in 
NGN via UPSF [5]: As an application server function may choose to use the repository function of the UPSF 
for hosting service-level user data, as transparent data, the interface should comply with Sh reference point 
used between this AS Function and UPSF. 

• The use of Sh reference point conforms to ES 282 007 [8]. 

• The IPTV applications represented on Figure 2, that may use the UPSF repository function are: Customer 
Facing IPTV Applications, IPTV control, IPTV subscriber management. 

5.2. 13 Ss' - access to SD&S data 

Optional Ss' reference point between Customer facing IPTV applications and SD&S used to retrieve service and 
optionally service provider information from the SD&S server, e.g. EPG, content metadata, service information 
updates, service provider details. 
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5.3 Generic IPTV Capabilities 



This clause describes generic IPTV capabilities - capabilities provided by IPTV functional entities and exposed via 
interfaces on the high level architecture. The capabilities are used to deliver a variety of IPTV services as defined in the 
detailed procedures. 

IPTV Generic IPTV CapabiHties: 

service discovery and selection; 

service control; 

service interaction; 

media control; 

media delivery; 

content protection; 

content management and distribution; 

interactions with other NGN services. 

5.3.1 Inter-destination media synchronization 

Inter-destination media synchronization is an optional generic capability, aimed at servicing corresponding service level 
requirement as defined in clause A.9.6 [1]. 

5.3.1 .1 Synchronization architecture 

The Media Synchronization Application Server (MS AS) and Synchronization Client (SC) are functions that provide 
inter-destination media synchronization. These functions are used for synchronization sensitive services for which IPTV 
delays and delay differences may degrade the quality of experience. The functional entities and reference point of the 
synchronization mechanism are shown in figure 4A. 



Media 

Synchronization 

Application Server 

(MSAS) 




— Sync 




Synchronization 
Client (SC) 



Figure 4A: Functional entities and reference points for inter-destination media synclironization 

5.3.1 .1 .1 Functional entities MSAS and SC 

The inter-destination synchronization mechanism uses the concept of synchronization sessions. Each synchronization 
session involves a Media Synchronization Application Server (MSAS) and multiple Synchronization Clients (SC). A 
synchronization session is used for the inter-destination synchronization of IPTV content (e.g. BC channel, CoD, UGC) 
by exchanging synchronization status information and synchronization settings instructions. 

• Synchronization status information: timing information on media reception at each SC. 

• Synchronization settings instruction: instruction how much an SC should delay the media stream. 
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Tasks of the SC: 

• Setting up and accepting synchronization sessions with/from the MS AS. 

• Sending synchronization status information to the MS AS. 

• Receiving synchronization settings instructions from the MS AS. 

• Delaying a media stream BC channel according to the received synchronization settings instruction. 
Tasks of the MS AS: 

• Setting up and accepting synchronization sessions with/from SCs. 

• Collecting synchronization status information from SCs. 

• Calculating synchronization settings instructions for the SCs. 

• Distributing synchronization settings instructions to SCs. 

NOTE: Examples of algorithms to calculate the synchronization settings instructions from collected 
synchronization status information may be found in [i.l]. 

5.3.1 .1 .2 Mapping onto the IPTV architecture 

The synchronization architecture can be mapped onto the IPTV architecture in the following ways. 
Mapping 1: SC in UE. 

• The MS AS is an elementary function of the IPTV Control. 

• The SC is an elementary function of the UE. 
Mapping 2: SC in Transport 

• The MS AS is an elementary function of the IPTV Control or a stand-alone Application Server. 

• The SC is an elementary function of the Transport Functions. 

NOTE 1 : Mapping 1 is aimed at small-scale deployments of services that require media synchronization and only a 
limited number of UEs uses media synchronization. Mapping 2 is aimed at large-scale deployment of 
media synchronization. 

NOTE 2: In mapping 2, the SC is an adjunct function that may be co-resident with any of the appropriate elements 
in the transport layer. 

5.3.1 .1 .3 IVIodification and re-origination of media streams 

In addition to inter-destination media synchronization, additional synchronization measures are needed in case a media 
stream is modified or re-originated during transport. Examples of these are transcoding, HD-to-SD conversion and 
user-generated comments to a live broadcast. In such cases, additional media- stream-modifying Synchronization Clients 
(SC) are placed at the functional entities where media streams are modified, see figure 4B. The Sync' reference point is 
used to exchange convey synchronization status correlation information between from the media- stream-modifying SC 
and to the MS AS on the synchronicity relationship between incoming and outgoing media streams. 

• Synchronization correlation information: timing information on the synchronicity relationship between 
incoming and outgoing media streams at an SC. 
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Figure 4B: Media synchronization in case of media stream modification 



5.3.1.2 



Synchronization reference points 



5.3.1.2.1 



MSAS-SC reference point (Sync) 



This optional reference point is between Media Synchronization Application Server (MSAS) and media- stream- 
synchronizing Synchronization Client (SC). It is used to set up synchronization sessions and to exchange 
synchronization status information and synchronization settings instructions with functional entities in the network 
where media streams are mutually synchronized. The Sync reference point is a logical reference point in Mapping 1 
from clause 5.3.2, where it is tunnelled over the Ct2 reference point. 



5.3.1.2.2 



MSAS-SC reference point (Sync') 



This optional reference point is between Media Synchronization Application Server (MSAS) and 

media- stream-modifying Synchronization Client (SC). It is used to set up synchronization sessions and to exchange 

synchronization status information with functional entities in the network where to-be- synchronized media streams are 

modified. 



5.4 Elementary functions 



This clause describes generic IPTV capabilities - capabilities provided by IPTV functional entities and exposed via 
interfaces on the high level architecture. The capabilities are used to deliver a variety of IPTV services as defined in the 
detailed procedures. 

General elementary functions: 

1) Network attachment 

2) Registration 

3) Resource Management 

4) Charging information 



ETSI 



26 ETSI TS 1 82 028 V3.3.1 (2009-1 0) 



IPTV elementary functions: 

Service related elementary functions: 

5) Service discovery 

6) Service authorization 

7) Service selection 

8) Service initiation 

9) Service control 

10) Service information handling (e.g. Metadata) 

11) Service configuration 
Session related elementary functions: 

12) Session initiation 

13) Session modification 

14) Session termination 

Service protection related elementary functions: 

15) Service key triggering function 
Multimedia delivery & control elementary functions 

16) Multicast based media delivery (media streaming) 

17) Unicast based media delivery (media streaming, both down- and/or upstream) 

18) Content download/upload (offline content transfer) 

19) Control of multicast based media streaming 

20) Control of unicast based media streaming (both down- and/or upstream) 

21) Control of content transfer by download/upload 

22) Content ingestion (receiving content) 

23) Content recording(capture of live content) 

24) Content storage 

25) Content adaptation (e.g. Transcoding, mix, substitute, personalize) 
Content management related elementary functions: 

26) Content acquisition 

27) Content validation 

28) Content distribution 

Content protection related elementary functions: 

29) Content licensing 

30) Content key management 

31) Content encryption 
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User management elementary functions: 

32) User profile/data management 

33) Accounting/right control 
IPTV Common elementary functions: 

34) Status/state (changes) detection/reporting 

35) Common notification 

36) Messaging 

37) Presence Reporting 

38) Inter-destination Media synchronization 



6 Operational framework 

6.1 IPTV delivery modes 

Integrated IPTV subsystem supports IPTV or NGN service using IP deHvery modes: 

• Unicast: deHvery mode where information packets are sent to a single destination. 

• Multicast: delivery mode of forwarding information packets to a group of destinations. 

• Combinations and interchanging of both inside a given service. 

In order to implement service level requirements defined in [1], integrated IPTV subsystem can use IP unicast delivery 
mode, for example, for Content on Demand service, or IP multicast delivery mode, for example, for broadcast TV 
service. More complex service scenarios are possible, where IP delivery modes are interchanged inside a single service, 
for example, to implement broadcast TV with trick modes. 

Unicast and multicast capabilities are expected from the transport layer. However, if only a subset of delivery 
capabilities is available, the functional architecture would implement functional capabilities build upon the available 
subset. For example, if transport layer has unicast capabilities only, the functional architecture implements CoD, nPVR 
and other services build upon unicast delivery. 



6.2 Operational modes 



This clause describes interactions between the UE, the Application functions and the "IPTV Service Control and Media 
Delivery functions". 

There are two aspects of these interactions: 

• Interactions between the Application functions and the "IPTV Service Control and Media Delivery functions". 

• Interactions between the UE and the "IPTV Service Control and Media Delivery functions". 

Concerning the first aspect, there are two possible modes of operations: coupled and decoupled. 

Coupled: following a request from the UE, the application communicates with the "IPTV Service Control and Media 
Delivery functions" to allocate and reserve a media delivery function before the content selection is confirmed to the 
UE. The URL to contact the "IPTV Service Control and Media Delivery functions" is returned to the UE. 

Decoupled: following a request from the UE, the application returns the URL to contact the "IPTV Service Control and 
Media Delivery functions" assuming that the "IPTV Service Control and Media Delivery functions" will be able to 
allocate a media delivery function and associated resources when needed. 
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Concerning the second aspect, there are two possible modes of operation: proxy and redirect. 

In the redirect mode: a functional entity receives an input request, performs its actions and redirects UE to the next 
functional entity in sequence. 

In the proxy mode: a functional entity receives an input request, performs its actions and proxies the request to the 
next functional entity in sequence. 

The flows for proxy and redirect modes are defined for one of the functional entities from "IPTV service control and 
media control functions. 

IPTV control is defined in redirect mode and MCF is defined in proxy mode. 

If one of the functional entities work in either of modes it neither mandates no precludes other functional entities to 
work in the same or alternative modes. 



6.2.1 Coupled mode 

Operational flow in the coupled mode is presented on figure 5. 
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Figure 5: Operation flow in tlie coupled mode 

Main functional steps in the coupled mode: 

1) Service Initialization: UE selects and requests service from the application. 

2) Profile Access: The application optionally access profile information withers from application data of via data 
access functions. 

3) Media Control Function Allocation: The application request a Media Control Function the UE can contact to 
requested media. 

4) User location: user location can be requested from NASS or from IPTV UDF in order to select the appropriate 
Media Delivery Function (and Media Control Function). 

5) Resources Reservation and Admission Control: IPTV service control and media delivery functions select a 
MCF and a Media Delivery Function and requests reservation of transport delivery resource (from UE to 
Media Delivery Function selected). 

6) Resources Reservation and Admission Control: transport resources reserved and committed. 

7) Media Control Function Allocation: Allocation of the user contact point in order to request media delivery and 
for interactive Media Control Function. 
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8) URL for Media Delivery to content Media Control Function functional entity. 

9) Media Delivery Request: UE requests interactive media delivery. 

10) Media delivery Function: UE controls interactive media delivery. 

6.2.2 Decoupled mode 

Operational flow in the decoupled mode is presented on figure 6. 
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Figure 6: Operation flow in the decoupled mode 

Main functional steps in the decoupled mode: 

1) Service Initialization: UE selects and requests service from the application. 

2) Profile Access: The application optionally access profile information withers from application data of via data 
access functions. 

3) URL for Media DeHvery. 

4) Media Control Function Allocation: Media Delivery Request. UE requests interactive media delivery. 

5) User location: user location can be requested from NASS or from IPTV UDF to select the appropriate Media 
Delivery Function (and Media Control Function). 

6) Resources Reservation and Admission Control: IPTV service control functions selects and media delivery 
functions selects a MCE and a Media delivery entities and requests reservation of transport delivery resources 
(from UE to Media Delivery Function selected). 

7) Resources Reservation and Admission Control: transport resources reserved and committed. 

8) Media Control Function Allocation: Allocation of the user contact point in order to request media delivery and 
for interactive Media Control Function. 

9) Media Delivery Request: UE requests interactive media delivery. The UE knows it has to send a second 
request because request at step 4 has resulted in redirect response as defined in clause 6.2.3. 

10) Media Delivery Control: UE controls interactive media delivery. 
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6.2.3 Redirect mode 

Operational flow of the IPTV control functional entity in the redirect mode is presented on figure 7. The flow represents 
operational. 
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Figure 7: Operation flow in the redirect mode 

Main functional steps in the decoupled mode: 

1) Media Delivery Request: UE requests interactive media delivery. 

2) Authorization Verification: IPTV control optionally verifies user rights to access the service. 
User Location: user location can be requested from NASS or from IPTV UDF. 



3) 
4) 



Resources Reservation and Admission Control: IPTV control selects media delivery function and optionally 
requests reservation of transport delivery resources. Note: resource reservation can be alternatively performed 
by the selected MCF. 



5) Resources Reservation and Admission Control: transport resources reserved and committed. 

6) Redirect to MCF: UE is redirected to MCF for the selected MDF function for interactive media delivery. 

7) Media Delivery Request: UE requests interactive media delivery. 

6.2.4 Proxy mode 

operational flow of the MCF control functional entity in the proxy mode is presented on figure 8. 
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Figure 8: Operation flow in the proxy mode 
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1) Media Delivery Request: UE requests interactive media delivery. 

2) Authorization Verification: MCF optionally verifies user rights to access the service. May access to IPTV 
UDF for this purpose. 

3) Resources Reservation and Admission Control: MCF selects media delivery function and optionally requests 
reservation of transport delivery resources. 

NOTE: Resource reservation can be alternatively performed by the IPTV control. 

4) Resources Reservation and Admission Control: transport resources reserved and committed. 

5) Media Delivery Request: Media Control Function command is passed to media delivery. 

6) Media Delivery: media is delivered to the UE. 



6.3 



Service initialization 



6.3.1 Functional steps for UE start-up 

Figure 9 presents functional steps of the UE start-up for IPTV subsystem in NGN. 
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Figure 9: UE start-up procedure 



1) Network Attachment. 



In this step, the UE attaches to the network. The UE may be passed data for Service Provider Discovery (SPD) 
as defined in clause 5.2.1. 

2) Service discovery. 

In this step, the UE discovers service providers and services as discussed in clause 5.2.1. 

3) IPTV security bootstrapping. 

In this step, the UE performs authentication, key management (CSP may be also involved in initial steps of 
service and content protection). During this procedure IPTV subsystem may register IPTV UE in other service 
level subsystems on behalf of UE. 

4) Attach to the IPTV Service. 

5) IPTV Service Configuration. 
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In steps 4 and 5, the UE navigates and selects a service from available service offers. IPTV AS may update IPTV user 
profile, presence of behalf of IPX V as a part of the SD&S process. The service navigation and selection can be provided 
in a generic case via different functional entity as presented on figure 10. 

NOTE: The high level service attachment steps can looks similar for integrated IPTV subsystem and IMS based 
IPTV approaches, the exact alignment in procedures is out of the scope of the present document. 

6.3.2 Service discovery and selection 

This clause defines steps in the service discovery and selection process used by the UE to attach to the network, acquire 
list of service providers and make service selection from the selected service provider. 

There is a step preceding SD&S process including setup and initial UE configuration. 

Figure 10 presents steps in the SD&S process. 
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Figure 10: High Level SD&S Process 

Network Attachment: during this step UE establishes connectivity to an IP-network and obtains network-based service 
configuration data. For example, the following information may be obtained or established by UE: IP address, network 
mask, DNS, domain name, others. During this step UE may be passed data for SPD, e.g. a container option sent by 
DHCP server listing the source IP address of the Service Provider server or list of registered IPTV service provider 
servers using DNS SRV mechanism in accordance with RFC 2782 [7]. 

Service Provider Discovery (SPD): during this step UE collects the location (entry points) for discovering service 
providers and retrieves information about available IPTV Service Providers, learns the location of their one or more 
Service Discovery (SD) Server. 

Service Discovery and Attachment: during this step UE acquires information about available IPTV Services from one 
or more Service Discovery (SD) Servers, navigate, select service from the service offering and attach to the service. The 
procedure used to activate a particular IPTV service is typically service specific. Authentication is performed at this 
step. 

Further decomposition for Service Provider Discovery (SPD) is presented on figure 1 1 . 
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Service Provider 
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Figure 1 1 : Service Provider Discovery (SPD) Steps 

Entry points discovery: during the step UE determines the entry point(s) for discovering service providers 
(e.g. bootstrap process). 

Service provider selection: during this stage UE retries information about available IPTV Service Providers, learns the 
location of their one or more Service Discovery (SD) Servers and makes a selection of the Service Provider. 

Different mechanisms are available for Step 2 and Step 3, e.g. those defined in DVB -IP [2] can be used. 

Regionalized or personalized delivery of the content metadata can be performed by the Customer Facing IPTV 
applications by accessing user profiles (as described in the Clause 8) and accessing user location (as described in 
clause 5). 

6.4 Nomadism 

In TISPAN Release 2, nomadism can be provided by relying on the functionality provided by the transport control 
layer (i.e. RACS and NASS). In this scenario, all functions in the integrated IPTV subsystem are located in the user's 
home domain and therefore, a UE in a visited access network or access point needs to be provided with: 

• IP connectivity to the user's home service control domain. 

• A pointer to the Customer Facing IPTV Application in the user's home service control domain (as part of the 
Service Discovery and Attachment procedures described in clause 6.3.2). 

6.5 Support of Mobility Capabilities 

Annex G discusses interconnection models for IPTV UE mobility. 

NOTE: If the UE supports roaming in the visited network to support mobility of IPTV services. 

Annex G considers how the UE in the visited network can access IPTV services from the home network. 

IPTV Service Provider in the home network may select to use MF in the home network to deliver content to UE in both 
home and visited networks. 



Security 



7.1 Content Protection 

For content protection the following elementary functions are used: 



• Content licensing: This elementary function handles the licenses issuing related functions, including 
generation and distribution of the licenses to the desired entities. 
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• Key management: This elementary function handles the management of the security keys on behalf of the 
content usage profiles as defined in the content licensing, including generate and provide the keys and 
corresponding parameters to the desired entities. 

• Content encryption: This elementary function handles the content protection related operations, e.g. content 
encryption and encapsulation operations, etc. 

These three elementary functions may be flexibly located in existing functional entities or new ones as a whole or in 
independent parts. 

NOTE 1 : The locations and related reference points of those three elementary functions are defined in 
TS 187 003 [11]. 

NOTE 2: Some of these elementary functions may be executed on-line (in real-time) or off-line (in this case could 
be part of the management). 

NOTE 3: Additional details and procedures for IPTV service and content protection of these three elementary 
functions and other IPTV security functions are described in TR187 013 [14]. 

7.2 Service Protection 

The service membership (SMF), Service Key Management (SKMF) and Service Protection (SPF) Functions described 
in this clause each involve a set of elementary functions required as part of a generic model for service protection. The 
SMF, SKMF, and SPF do not duplicate, but collaborate and interact with existing elementary functions in order to 
perform service protection. 

For service security the following functions are used: 

• Service Membership elementary Functions (SMF): This set of elementary functions handles the granting and 
revoking of service access rights to access the IPTV services. Metadata related to the service rights 
management are maintained by the SMF. 

NOTE 1: The SMF is handled in an array of existing elementary functions (e.g., service key triggering function) 

and functional entities. For example, service authorization may be provided by the CFIA or IPTV-C, and 
meta-data is maintained in the UPSF. 

• Service Key Management Function (SKMF): This set of elementary functions acts on behalf of the Service 
Membership Function and as such manages service security keys, including generating and providing keys and 
corresponding parameters to the desired entities. 

• Service Protection Function (SPF): This (set of elementary) function(s) handles the service protection related 
options, e.g. service confidentiality, integrity operations and authorization at the service access point, etc, using 
the keys generated in SKMF. 

NOTE 2: The SPF includes group association, e.g. multicast group. 

NOTE 3: The locations and related reference points of those three elementary functions are defined in 
TS 187 003 [11]. 

NOTE 4: Additional details and procedures for IPTV content protection are described in TR 187 013 [i.4]. 



8 Management 



A number of functional entities used to deliver IPTV and NGN services require time synchronization, e.g. to provide 
time of day reference. Transport layer should support such reference. 

Content management functionalities are responsible for managing acquisition of content and service information 
(e.g. metadata) from sources, controlling validation and/or processing/adaptation to the required format and also to 
provide management functionalities for supporting distribution of content to the media delivery function. 
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NOTE: Content management is used in the case of offline or online ingest of the content. The onHne ingest means 
receiving content directly streamed from the content provider. The offline ingest refers to content files 
delivered by other means than the online (e.g. such on physical media like DVD, CD, etc.). The content 
management is used by the IPTV service provider to statically provision the content. 



9 User data 

9.1 IPTV profiles 

IPTV related data can be grouped into three types of IPTV profiles (see figure 12): 

• Content Profile. 

• Service Profile. 

• User Profile. 
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Figure 12: NGN IPTV profiles 

Content Profile: Content profile contains and maintains information about multimedia metadata and multimedia 
service packaging used for the provisioning of IPTV services. 
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Figure 13: NGN IPTV Service Profile 

Service Profile: Service profile refers to data used to the provisioning of the service to the user. It contains and 
maintains information about service-level user data and service-level offer data (see figure 13): 

• Service-level user data: as defined in NGN Functional Architecture [5], e.g. user identification, numbering, 
addressing, user security, location information at inter-system level, other. 

• Service-level offer data: contains the information for delivery of IPTV services, e.g. EPG/BPG. 

User profile: User profile refers to user customization and usage metadata. It contains and maintains basic user 
information, service specific information, e.g. subscription, bookmarks, activities, parental control, etc. and User actions 
related to service purchase and consumption. 
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• User subscription data - contains information such as language preference, payment preferences, navigation 
preferences, etc. 

Service actions data - contains and maintains non static data related to the purchase and consumption of services such as 
list of CoD already consumed, indexes for currently consumed programs, language selection. 

9.2 User data location 

NGN Integrated IPTV supports two approached to user data location: federated and consolidated. 

In the federated approach user data is located close to associated AS functions in IPTV UDF, NGN Apps UDFs. 

User data associated with applications can be access by the AS functions directly on Ud interfaces. If AS function 
requires access to subset of user data associated with other AS functions, Ug interface should be used. User Data 
functional acts as data federation agent providing unified approach and federation of user data profiles. 

Federated approach is applicable to other data profiles defined in clause 9.1: 

• content profiles; 

• service profiles. 

In the consohdated approach user data is located in a single location: User Data Function and can is accessed on Sh 
interface. Ud and Ug interfaces, in essence, become the same Sh interface. 

As discussed above, both lUDF and UPSF may be used for handling the IPTV user data. 

IPTV profile information (Content, service, user, as defined in clause 8.1) could be optionally located in the IPTV 
Application server functions (i.e. lUDF) hosting the IPTV applications, or in the UPSF as transparent data associated to 
the Application Server functions, or in an XDMS associated with the IPTV Application Function. 

The type of user related information necessary for multi-subsystems service blending belongs to the following list: 
service-level user identification, numbering and addressing information, service-level user security information: access 
control information for authentication and authorization, service-level user location information at inter-system level, 
service-level user profile information. 

To provide support for converged applications that span across several subsystems of the TISPAN NGN network 
(e.g. chatting on watched programs, multiple incoming calls management, as listed inTS181016[l]) both federated 
and consolidated approaches are applicable, and in accordance the location of the user data profile: 

• Use UPSF as the host for the set of user related information necessary for multi-subsystems service blending. 

• Use of data federalization (represented by UDAF on figure 2). 

It is recommended that an NGN (e.g. converged) application, or its corresponding user data functions do not have direct 
access to IPTV profiles in lUDF (reverse applies respectively). It may however have access to it by other means 
(e.g. Ug reference point to UDAF, Sh to UPSF for the subpart of IPTV profile that is hosted onto UPSF. 

If UPSF is used, several entities will need to be consistently provisioned for: 

• user identification (in UPSF and lUDF); 

• user authentication (in UPSF and lUDF). 

NOTE: Such need for consistent provisioning is to be brought to the attention of WG8. 



10 Charging 

As illustrated in figure 2, the charging belongs to the management domain. 

IPTV subsystem collects information related to billing and provides IPTV CDRs (including charging related elements), 
that can be collected by the billing system for the sake of off-line charging. These CDRs may also be used for other 
purposes than billing (such as QoS, statistics). 
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NOTE: CDR means Charging Data Record, as defined in TS 132 240 [13] (endorsed by ES 282 010 [12]). It is a 
formatted collection of information about chargeable event, knowing that, as a minimum, a chargeable 
event characterizes the resource/ service usage and indicates the identity of the involved end User (s). 

IPTV subsystem integrates with the charging and accounting components of the management domain for having access to 
the user account (credit, balance, etc.) in order to allow IPTV user facing applications and optionally media delivery 
control to perform their role with. 



11 



Procedures 



11.1 Linear TV 

This clause provides the flows for the BTV IPTV services integrated into the TISPAN NGN architecture and 

inter- working with the NGN common functions and components. The flows support linear TV in coupled and decoupled 

mode. Linear TV in coupled and decoupled mode uses RAGS in the "push mode". 

The clause presents generic flows and does not mandate placement of functions. DRM flows are not included. 

Linear TV procedure for coupled and decoupled mode. 
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Figure 14: NGN IPTV Linear TV procedure for coupled and de-coupled mode 

1) UE requests SD&S information from SD&S. SD&S format and request methods are outside the scope of the 
present document and have been researched in other specifications, e.g. [2], others. 

2) SD&S verifies user profiles from lUDF/UPSF. The location of lUDF/UPSF and data model, e.g. centralized or 
federated is described in clause 9. 

3) SD&S replies service offers to UE. 

4) MDF outputs BTV multimedia stream, such as regular TV channels or scheduled content, to the TPF 
connected via MGF. 

5) UE requests TPF to join linear TV channel A (BTV multicast stream). 

6) Optionally, resource admission control may take place at this stage. For Multicast, this is typically performed 
by an A-RAGF, which can be separately located or collocated with the TPF [10]. 

7) Ghannel A is delivered. 
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8) UE requests TPF to leave linear TV channel A. 

9) If resource admission control was executed in Step 6, resource release procedure shall take place at this stage. 

10) UE requests TPF to join linear TV channel B. Optionally, local admission control can check resource 
availability before granting the request. 

11) Optionally, resource admission control may take place at this stage. For Multicast, this is typically performed 
by an A-RACF, which can be separately located or collocated with the TPF [10]. 

12) Channel B is delivered. 

NGN Linear TV IPTV session is a lasting service agreement and reserved network delivery resources for broadcast 
multimedia service between UE and TPF, e.g. between and including steps 5) and 8) on figure 14. 

Typically in the coupled mode UE would access the channel (step 4) immediately after step 3. 

In the decoupled mode there could be a time delay between step 3 and step 4, e.g. user may be authenticated to access 
bTV package at the service initialization stage (steps 1-3), but choose to view channel from the package at the later time 
(step 4). 

NOTE: This and subsequent flows show separate location of the TPF and RACS, they can be co-located as 
discussed in [10]. 

1 1 .2 Multimedia content on demand (CoD) 

This clause provides the flows for the CoD IPTV services integrated into the TISPAN NGN architecture and 
inter- working with the NGN common functions and components. 

The clause presents generic flows and does not mandate placement of functions. DRM flows are not included. 
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Figure 15: NGN IPTV CoD procedure 

1) UE requests SD&S information from SD&S. SD&S format and request methods are outside the scope of the 
present document and have been researched in other specifications, e.g. [2], others. 

2) SD&S verifies user profiles from lUDF/UPSF. The location of lUDF/UPSF and data model, e.g. centralized or 
federated, is described in clause 9. 

3) SD&S replies service offers to UE. 

4) User selects a service from the offers. UE requests the selected service from Customer Facing IPTV 
Applications. 

5) Customer Facing IPTV Applications. Optionally creates billing event, e.g. for on-line billing, and sends it to 
lUDF/UPSF. The location of the billing information and data model are discussed in clause 9. 

6) Customer Facing IPTV Applications optionally creates authorization record (play ticket) to authorize content 
delivery. 

7) Customer Facing IPTV Applications replies the location of IPTV control and optionally ticket data to UE. 

8) UE requests IPTV control the location of MCF. Optionally ticket data is supplied. 

9) IPTV Control selects MCF based upon operator defined criterions and requests RACS to allocate resources 
between the end-points. Distributed RACS interfaces are allowed. 

10) IPTV Controls repHes MCF location to UE. 

11) UE requests MCF to deliver media using reserved session and associated resources. Optionally ticket data is 
supplied and the ticket punched. 
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12) MCF optionally verifies user credentials to request multimode delivery. 

13) UE utilizes VCR style control over media to MCF. 

14) Automatic resource reservation follows session termination, which can be initiated either by end point UE or 
MCF, or by an IP network. Although it is not necessary to explicitly tear-down an old reservation, we 
recommend that during normal operation MCF or IPTV Control send a teardown request to RACS as soon as 
the session has finished. 

NGN CoD IPTV session is a lasting service agreement and reserved delivery resources on server and network levels for 
multimedia on demand service between UE and MDF. 

Cod flows do not cover NAT explicitly, however, standard IP NAT protocols can be used, see [14]. 

1 1 .2.1 Optimized bandwidth utilization during CoD 

This clause discusses optimized bandwidth utilization during CoD procedure for UE containing local storage. 

The MDF, during media delivery initiated by Step 13 on Figure 15, may increase the bandwidth of the session to a 
higher bandwidth once the session has been opened, to permit delivery of data from MDF to the UE at a rate higher than 
the nominal reserved rate. The excessive content should be saved on the local storage for further consumption. The 
content "burst" may come with a different network priority or class of service. 

The UE may optionally provide feedback to the delivery server, e.g. the UE may detect missing data and to request 
missing packets from the delivery server using a retransmission approach and a RTP/RTCP feedback mechanism 
specified in clause A. 3 [1]. 

The MDF may increase the bandwidth gradually, waiting for the results of feedback received by the delivery service: 
the MDF increase the bandwidth gradually until a retransmission request is received, and, once the retransmission 
request has been received, to reduce the bandwidth gradually until retransmission requests are no longer received. The 
delivery server may cyclically increase and decrease the bandwidth, in accordance with the retransmission requests. 

Optimized bandwidth utilization enables more efficient utilization of the network resources and capacity, e.g. since the 
content can be delivered faster (e.g. at the idle times) and RACS resources to be released earlier (e.g. to meet peek 
demands). 

Figure 15.2 illustrates Optimized bandwidth utilization during CoD. 
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Figure 15.2: Optimized bandwidth utilization during CoD 
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1) CoD session setup as discussed in clause 1 1.2. During session setup at SD&S stage the UE has been identified 
as containing local storage and enabled for optimized network utilization mode. 

2) Content media flow from MDF to UE. 

3) MDF increases delivery bandwidth. 

4) Content media flow from MDF to UE. 

5) Media loss detected. Request for missing data. 

6) MDF requested retransmission of missing data. 
Steps 3-6 can be repeated. 

1 1 .3 Media broadcast with trick modes 

This clause provides the flows for the media broadcast with trick modes IPTV services integrated into the TISPAN NGN 
architecture and inter- working with the NGN common functions and components. 

The clause presents generic flows and does not mandate placement of functions. DRM flows are not included. 
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Figure 16: NGN media broadcast with trick modes procedure 

The flows shows generic case where MDF providing linear TV is not co-located with MCF providing "on-demand" 
functionality. MCF and MDF can be located in the same place. 

1) UE requests SD&S information from SD&S. 

2) SD&S verifies user profiles from lUDF. 

3) Media broadcast with trick modes is a subscription based service. At the subscription time, Customer Facing 
IPTV Applications optionally create authorization record (play ticket) to authorize this service. 
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4) SD&S is returned to the user. 

5) MDF outputs BTV multimedia stream, such as regular TV channels or scheduled content. 

6) UE requests transport to join linear TV channel A (BTV multicast stream). Optionally, resource admission 
control may take place at this stage. For Multicast, this is typically performed by an A-RACF, which can be 
separately located or collocated with the Transport Processing Function [10]. This is shown by a dotted line. 

7) Channel A is delivered. 

8) User requests to pause linear TV channel. UE requests transport to leave linear TV channel A. 

9) User requests to re-start play from the paused position. UE issues setup command and requests IPTV Control 
the location of the MCE. Optionally ticket data is supplied. This selection is optional, previously selected MCE 
can be used or the default MCE can be supplied to the UE during service initialization steps. 

10) IPTV control selects MCE based upon operator defined criterions and requests RACS to allocate resources 
between the end-points. Distributed RACS interfaces are allowed. 

1 1 ) IPTV control repHes MCE location to UE. 

12) UE issues play command and requests MCE to deliver media from the pause position supplying position. 

13) MCE optionally verifies user credentials to request multimode delivery. 

14) UE utilizes VCR style control over media. 

15) Automatic resource release follows session termination, which can be initiated either by end point UE or MCE, 
or by an IP network. Although it is not necessary to explicitly tear-down an old reservation, we recommend 
that during normal operation MCE or IPTV Control send a teardown request to RACS as soon as the session 
has finished. 

Return to live linear TI channel is achieved by repeating steps 6) and 7). 

Return to trick mode is archived by repeating steps 8) to 13). 

NGN IPTV media broadcast with trick modes service is combination of separate BTV and CoD IPTV sessions joined 
together at the service level. See clause 11.1 for definition of CoD NGN IPTV session and clause 1 1.2 for definition of 
BTV NGN IPTV session. 

NGN IPTV media broadcast with trick modes session is a service level aggregation as defined above and is not used for 
billing purposes. 

11.4 Near CoD 

This clause provides the flows for the Near CoD IPTV services integrated into the TISPAN NGN architecture and inter- 
working with the NGN common functions and components. 

The clause presents generic flows and does not mandate placement of functions. DRM flows are not included. 
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Figure 17: NGN IPTV near CoD procedure 

The flow represents a generic case where MDF provides a CoD content on a set of multicast channels with a fixed 
interval, e.g. an interval of 15 minutes. 

For example, one content's playback time is 148 minutes. 

Near CoD Channel starts output stream at time offset 00 minutes. 

Near CoD Channel 1 starts output stream at time offset 15 minutes, and so on until Near CoD Channel 9 starts output 
stream at time offset 135 minutes. 

1) IPTV Control requests the MDF to initiate the Near CoD channels. 

2) MDF outputs Near CoD channel streams to the transport. 

3) UE requests the Near CoD services information from SD&S. 
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4) SD&S checks the user profiles from lUDF/UPSF. 

5) SD&S returned Near CoD Services offered. 

6) UE purchases the Near CoD from CF IPTV AppHcations. 

7) CF IPTV AppHcations updates the user profiles from lUDF/UPSF to record the purchase. 

8) CF IPTV Applications returned the Channel list of the Near CoD Service which the user just purchased. Each 
channel has information of Start Time and End Time. 

9) UE requests transport to join Near CoD channel / which was the next rolling start channel by the time of the 
request. 

10) Optionally, resource admission control may take place at this stage. For Multicast, this is typically performed 
by an A-RACF, which can be separately located or collocated with the Transport Processing Function [10]. 

11) Near CoD Channel / is delivered. 

12) User requests to Skip Forward. UE requests transport to leave Near CoD Channel +7. 

13) UE requests transport to join Near CoD channel +i+l which was the next channel. 

14) Optionally, resource admission control may take place at this stage. For Multicast, this is typically performed 
by an A-RACF, which can be separately located or collocated with the Transport Processing Function [10]. 

15) Near CoD Channel /+7 is delivered. 

16) User requests to Stop or End play the Near Cod. UE requests transport to leave Near CoD Channel +i. 
Step (1) and (2) is the flow of setup of Near CoD. 

Step (3) to (8) is the flow of Service Discovery & Selection of Near CoD. 

Step (10) to (17) is the flow of UE playback control of Near CoD. Steps (12) to (16) are the optional interaction flow 
during the playback of Near CoD. Steps 12-15 applicable for other trick mode operations: e.g. skip backward. 

11.5 Push CoD 

1 1 .5.1 Push CoD procedures using notification 
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Figure 18: Push CoD services procedure 
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The detailed description of procedure is following: 

1) User subscribes to Push CoD service. 

2) According to policies the CFIA may request IPTV sub-profile of federalized user profile from lUDF or UPSF. 
CFIA decides user authorization to use a service based on received information and service logic. 

3) CFIA authorizes request and confirms successful subscription to the UE. 

NOTE: IPTV Service provider may initiate Push CoD without explicit user subscription in which case 1-3 may be 
optional. 

4) New Push CoD event acts as a trigger for CFIA 

5) CFIA delivers notification to the UE (including CoD content identifier) using notification framework 

6) UE may accept delivery of Push COD 

7) UE initiate via IPTV-C either CoD content delivery as described in clause 1 1.2 or CoD content download from 
MDF. The content may be either viewed immediately or stored for later vie wings. 

1 1 .6 User generated content 

11.6.1 Overview 

There are two types of User Generated Content (UGC) procedures: 

• creation of the User Generated Content: this type of procedure allows a user to declare UGC with its 
metadata and upload/upstream his/her own content to the network as discussed in clause A.9.1.2 [1] and in 
accordance with the IPTV SP policies for UCG services. 

• watching of User Generated Content: this type of procedure allows a user to select and watch User 
Generated Content. 

NOTE: The UGC watching procedure may start before the UGC creation procedure has been completed, e.g. as 
defined in Clause A.9.1.2 [1]. 

1 1 .6.2 UGC creation procedure 

The UGC creation procedure comprises four major steps: 
Step 1 : Declaration of User Generated Content. 

• The UE sends a User Generated Content creation request to the CFIA and receives a content ID for the UGC 
from the CFIA. The content ID is independent of the address where the UGC can be retrieved by other UEs. 

Step 2: Publication of User Generated Content information by the UE. 

• The UE sends a request to the CFIA that contains a description of the User Generated Content (name, type, 
restriction, textual description, special group users, etc.). This request may be combined with the User 
Generated Content Declaration request in step 1 . 

Step 3: Creation of User Generated Content. 

• The UE initiates a session with the CFIA and MF in order to create the User Generated Content (i.e. 
upload/upstream (unicast) the content to the MF). The MF provides the CFIA with the location at which the 
UGC becomes available. 

Step 4: Publication of User Generated Content information by the CFIA. 

• The CFIA establishes the relationship between UGC content ID, UGC description, and optionally the MF, and 
publishes this UGC description information to the SD&S. The UGC description publication by the CFIA in 
step 4 may take place before, during or after the UGC content creation delivery session initiation in step 3. 
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Step 1 is always the first step. Step 2 may happen at any time during the UGC creation and can be repeated during the 
Hfetime of the content. 
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Figure 19: UGC creation procedure 

The UGC procedure comprises the following major steps: 

1) The UE sends a request for User Generated Content declaration. 

la) The UE sends a User Generated Content Declaration Request to the CFIA. This request asks for a unique 
content ID (that is independent of the address where the UGC can be retrieved by other UEs). 

lb) The CFIA may check user rights and user profile prior to granting the UE permission to create UGC and 
generates a unique UGC ID. 

Ic) The CFIA confirms that the UE can create UGC by sending a Declaration Response containing the UCG 
ID and the designated MCF/MDF where the UCG can be created (uploaded/upstreamed). 

2) The UE sends a request for UGC description: 

2a) The Description Request contains a description of the User Generated Content (e.g. name, type, 
restriction, textual description, selected group users, type of content, coding). 

2b) The CFIA records the UGC description, establishes the relationship between UGC ID and UGC 
description and sends a UGC Description Response to the UE. 

3) UE initiates creation of User Generated Content for uploading or upstreaming the content to the designated 
MDF and confirms to the CFIA the publication of content (making it available for usage). 

4) The CFIA establishes the relationship between UGC ID, UGC description and optionally UGC location 
(address), and publishes this UGC information to the SD&S. The UE can modify or terminate the established 
UGC creation session at a later stage. 
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1 1 .6.3 UGC watching procedure 

The UGC watching procedure comprises two major steps: 

Step 1: Selection of UGC: 

• The selection of the UGC may be done through the SD&S. Alternatively, UGC selection can be triggered by a 
content recommendation or a notification. The UE may also pre-select UGC that has already been declared 
and published (see clause 11.6.2, steps 1, 2 and 4), but not yet created (see clause 11.6.2, step 3). 

Step 2: Watching of UGC: 

• Session initiation can be performed by the UE or the CFIA in order to watch the selected UGC. The UGC 

watching session is equivalent to the CoD session. If the UE has previously pre-selected UGC that had already 
been declared and published but not yet created (see above), then this UGC will be delivered in an Push CoD 
session (see clause 11.5.1, figure 18) when the UGC is created. 
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Figure 19A: UGC watching procedure 



1) The UE selects UGC through service selection procedure with SD&S as defined in clause 8.2 step 4. The 
SD&S may restrict the list of UGC depending on user identity and UE capabilities. Alternatively, UGC 
availability is triggered through the notification procedure from the CFIA as defined in clause 1 1.8.2 or 
recommendation procedure from the CFIA as defined in clause 1 1.9.2. The UE may also pre-select UGC that 
has already been declared and published (clause 11.6.2, steps 1, 2 and 4), but not yet created 
(see clause 11.6.2, step 3). This UGC pre-selection is described in steps la) - Ic). 

After publication, the CFIA can send a notification for the availability of UGC to selected UEs (using the 
existing mechanism from clause 11.8.2). 

The notification can trigger the delivery of UGC to selected UEs of one or more users (e.g. based on a user's 
subscription) using existing procedures (e.g.. Linear TV defined in clause 11.1 or Multimedia CoD defined in 
clause 11.2). If the user pre-selected UGC, then this UGC will be delivered using Push CoD (see clause 11.5.1, 
figure 18) and the UE automatically accepts the notification and initiates a watching session to the MF. 

The UE can modify or terminate the established UGC creation session later on. 
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1 1 .7 Pay Per View 



Thus clause discusses pay per view service. PPV service provides access to regular IPTV content (e.g. BC, CoD, UGC) 
through packaged service offers (e.g. pay per packages of assets, pay per specific program or pay per series) with 
pre-defined access conditions (e.g. pay per number of views or access time). PPV service is defined by IPTV SP. 

Notification service may be used to notify the UE about available PPV services. Alternatively, the UE may select PPV 
services from available offer using SD&S. 

NOTE: PPV package may contains combination of multiple IPTV content (e.g. BC, CoD, etc.) within single PPV 
service offer. 
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Figure 19B: PPV services 

High level description of service procedure: 

1) User subscribes to PPV service. 

2) The CFIA may request IPTV sub-profile of federalized user profile from lUDF or UPSF. CFIA authorizes 
access to the service based on User Profile and service access logic (e.g. pay per view /time / number of plays). 
Payment may be requested and/or user credit may be checked before authorizing service access. 

3) CFIA authorizes request and confirms successful subscription to the UE. 

4) UE chooses to use PPV service and requests delivery of PPV content via existing procedures (e.g. Linear TV in 
11.1, Multimedia content on demand (CoD) in clause 1 1.2 or User generated content in 1 1.6). PPV may provide 
access for a limited period to the specified content (e.g. TV channels, CoD assets, etc.). CFIA may need to push 
access control via IPTV-C to RACS and revoke when PPV service expires. 

5) Expiration of PPV purchase acts as a trigger for CFIA. 

6) CFIA delivers notification about expiration in advance to the UE (including timeout when service ends or offer 
to extend PPV period) using notification framework. 

7) PPV service is terminated and also resources are released using existing procedures (following procedures used 
for service initiation in step 4). 
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1 1 .8 Messaging and notification services 
1 1 .8.1 Messaging procedures 

If messages are delivered via CFIA, then the role of Common NGN ASF is to terminate and process multiple incoming 
messages into generic format before passing to CFIA for presentation to the UE. This is illustrated by the figure below. 
The responses from the UE via CFIA should be passed back to Common NGN ASF, which will route the messages to the 
appropriate destination. 
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Figure 20: Messaging between IPTV UEs 

Messaging between IPTV UEs: 

1) User 1 sends a message from UEl to the IPTV user 2 at the UE2. 

2) The UEl sends request with attached message and recipient identifier to the CFIA. 

3) The CFIA forwards message to the NGN ASF messaging server. 

4) According to poHcies the NGN ASF may request IPTV sub-profile of federaHzed user profile from NGN lUDF 
if this information is not stored in NGN ASF. The NGN ASF identified destination UE based on policy and 
destination information. 

5) Based on policies the NGN ASF decides that the message should be forwarded to the IPTV UE2. The Common 
NGN ASF informs CFIA about the incoming message. 

6) The CFIA delivers message to the UE 2. 

7) Successful delivery is confirmed to UE 1 via CFIA. 

8) Successful delivery is confirmed to UE 1 via CFIA. 

9) The message is presented to user 2. 

NOTE: The message can be directly delivered from and to Common NGN ASF. 



1 1 .8.2 Notification procedures 



Common notification framework should be used for notifications about services from internal elements, e.g. CFIA or 
NGN applications (NGN ASF) to IPTV UE as described in procedures below. Such notifications can include, for 
example, emergency alerting, advertising, content recommendation or maintenance notification. 



ETSI 



50 



ETSI TS 182 028 V3.3.1 (2009-10) 



UE1 



IPTV ASF 
(CFIA) 



NGN ASF 
(or IPTV-C) 



1 . Subscribe Notification service 



Jl. Confirmed subscription 



UPSF/ 
User Data 



3. Notification event 



X 



4. Check profile & notification 
message rules 



S ^ Send notification 
6. OK 



7. Deliver Notification message to UE1 



8. OK 



9. Message presented to UE or 
store in message box 



Figure 21 : Procedure for notification services 

Procedure for notification services: 

1) User 1 subscribe to Notification service. 

2) IPTV control (or NGN ASF) authorizes and confirms successful subscription to notification service. 

NOTE 1 : Step 1 and 2 may be performed via CFIA. 

NOTE 2: IPTV Service provider may initiate notification service to the UE, e.g. for maintenance purposes without 
explicit user subscription in which case 1-2 may be optional. 

3) New notification event acts as a trigger. 

4) According to policies the IPTV-C may request IPTV sub-profile of federalized user profile from lUDF or 
UPSF. IPTV-C decides user authorization and the appropriate UE to send notification to. 

5) IPTV-C inform CFIA about notification event 

6) CFIA acknowledges notification event. 

NOTE 3: Step 5 and 6 are optional, e.g. when NGN ASF or IPTV-C notifies the UE directly. 

7) Notification message is delivered to UE (via Tr reference point). 

8) Successful delivery is confirmed to IPTV-C (or NGN ASF as external notification server). 
NOTE 4: Step 1 and 2 may be performed via CFIA. 

9) Message is present to user or stored on UE for future presentation. 

1 1 .9 Recommendations 

The Content and Service Recommendation Service (CRS) is used for providing recommendations to IPTV users or user 
groups. 

The recommendation service may make recommendations to user/groups based on different criteria which include user 
profile, preferences settings, current viewing habits, historic user activities as defined in [1]. 

The recommendation may be in form of text message (notification), multimedia message, content bookmark (pointer to 
recommended content) or video recommendation streamed from MDF. 
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The CRS service procedures include 2 main functions: 

1 ) Aggregation of metadata for recommendations, e.g. : 

a) List of users with unique identifiers and associated service profiles. 

b) Asset metadata for CoD and linear TV, EPG/BCG. 

c) Historic information about user consumption of IPTV services. 

2) Generation of recommendations on request of external triggers. 

The architecture supports different ways to deliver recommendations to the UE. Typically, content recommendations 
could be included into customer facing IPTV application. However, other delivery means are possible, e.g. common 
notifications framework can be used to deliver recommendations as defined in clause 11.8. The notifications framework 
can be used e.g. to deliver time-sensitive recommendations to the user. 

1 1 .9.1 Recommendations overview 

A high level procedure for content and service recommendations is presented on figure 22. 
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Figure 22: High Level Procedures for CRS 

1) Aggregation and user configuration of profile or preferences for CRS. 

NOTE: This user configuration part of the step is optional. The recommendations may be based only on IPTV SP 
user profile. 

2) An application detects recommendation opportunity and requests for content recommendations. For example, 
such an event could be a user action of accessing or navigating CFIA, changes in the presence state or change 
in the service offers. 

3) The application after detecting recommendation opportunity may send recommendation notifications to the UE 
immediately (push based CRS, push from CRS towards UE). Notification framework (described in 

clause 11.8.2 Notification procedures) is used to deliver CRS recommendation notifications (e.g. as a text 
message (notification), multimedia message, content bookmark, pointer to recommended content). 

4) CFIA may provide CRS recommendation data, e.g. in addition to SD&S services information during service 
navigation the recommendations may be included into the CFIA user interface. In this case step 3 is optional. 
The UE may request additional data at step 4 (e.g. advertising clips, previews, trailers, etc). 

1 1 .9.2 Recommendations procedures 

This clause describes intermediate level procedures for content and service recommendations. 
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Figure 23: Aggregation and configuration of user profile 

Aggregation of metadata for content recommendations: 

1) User can update his preferences and profile at the chosen time. 

2) The updates are incorporated into the user profile. 

3) User Profile data is pushed to the CRS. 

4) BTV and CoD asset metadata is pushed to the CRS. 

5) User consumptions of CoD or BTV content is pushed to the CRS. 

6) User consumptions of BTV channels and optionally time on the channel is pushed to the CRS. 

NOTE 1: Steps 3.. 6 are illustrated in the push mode. Alternatively, CRS can pull this information in the pull mode. 
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Figure 24: Recommendation request and delivery 

Recommendations Request and Delivery 

1) UE requests SD&S information from SD&S. 

2) SD&S verifies user profile from lUDF/UPSF. The location of lUDF/UPSF and data model, e.g. centralized or 
federated is described in clause 9. 

3) If service selection is included into CFIA then CFIA can optionally request CRS recommendation in addition 
to SD&S services according to the user profile. 
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4) CRS returns recommendations for multiple services according to user profile, e.g. recommendations for bTV, 
CoD. 

5) Personalized service offers with recommendations are returned to the UE. 

6) User navigates through IPTV services. 

7) CFIA requests CRS recommendation for user selected service. 

8) CRS returns recommendations for the selected service according to user profile. 

9) Service options with personalized recommendations are delivered to the UE. 
NOTE 2: The service delivery itself is not affected by the service recommendations. 

11.10 Advertising 

NGN Integrated IPTV Advertising (Ad) service supports the following procedures: 

1) Targeted ad insertion: Ad content is provided to the UE during the IPTV CoD or bTV session based on the 
user profile (user preference, historic metadata, location information, presence state). The ad content is 
provided at the predefined time or place: e.g. during commercial breaks on BTV channels, during PAUSE in 
the trick mode or as pre-roll/post-roll for CoD asset. 

2) Interactive Advertising (push/pull): Advertising content offered to the user (e.g. red button) and triggered by 
the UE selection. The UE may be able to interact with some content. 

3) Regionalized/localized Ad-insertion: Ad content (local or regionalized) is inserted into the IPTVbroadcast 
stream without targeting specific users or user groups. However, it may be targeted to regions or zones 
depending on network topology. 

If targeted advertising is supported, the targeting could be towards individual users or specific user groups. 

Targeted advertising may be based on multiple criteria, e.g. user profile, preference, presence information, watched 
content, shopping habits, location. Advertising can contain user actions, e.g. to allow user purchasing advertised 
content, services or take other actions. 



11.10.1 Advertising procedures 



Ad insertion implies that an IPTV session exists prior to the insertion time. The targeted ad is selected by the ADSS (Ad 
Selection Service). 

The following ad insertion opportunities exist for multicast (e.g. bTV) and unicast (e.g. trick modes, CoD, nPVR, tsTV) 
based services. 

Ad insertion opportunities for unicast based services: 

1) Pre-roll (a placement opportunity preceding an entertainment asset). 

2) Post-roll (a placement opportunity following the play out of an entertainment asset). 

3) Interstitial (a placement opportunity occurring during the play out of an entertainment asset). 

4) Pause (placement opportunity as a result of a subscriber pressing the pause button). 

5) Overlay (overlay triggers, e.g. overlaid red button triggering interactive ads). 
Ad insertion opportunities for multicast based services: 

1) Ad breaks (placement opportunity typically indicated by in-band ad-insertion markers within IPTV content, 
which is allowed to be replaced by ads). 

2) Overlay (overlay triggers, e.g. overlaid red button triggering interactive ads). 

3) Interstitial (a placement opportunity occurring during the play out of an entertainment asset). 
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The ad insertion can be performed at either UE side or MF side: 

• When UE performs ad insertion, it is informed or determines ad insertion opportunity, receives both IPTV 
content and ad content, and renders them in a sequential or simultaneous way. 

• When MF performs ad insertion, it is informed or determines of ad insertion opportunity, retrieves ad content 
and delivers the combined stream to the UE. 

The major steps of TAI are as follows: 

• Placement opportunity detection. 

• Ad content selections. 

• Ad content delivery and presentation. 

1 1 .10.2 Network side unicast based advertisement 

This clause defines network side advertisement procedures for pre-roll, post-roll and pause ad placement opportunities 
discussed in clause 1 1 . 10. 1 . 

Figure 25 presents network side pre-roll and post roll advertisement procedure for unicast based services. 

The procedure is applicable for the following services: 

• Content on Demand. 

• Network PVR. 

• Time-shift TV. 




-42. User Profile 
3. 1 



-6. Instruct to create personalised play-list- 
7. 



-8. Acknowledgement and personalised playlist- 



9. Unicast Session Setup 



-4. Ad Requests 
4 5. 



Figure 25: Pre-roll and post-roll advertisement for unicast based services. 

1) User selected a content following SD&S procedure discussed in clause 6.3. 

2) CFIA optionally requests current profile in order to request an ad. 

3) UPSF/IUDF returns current profile. 

4) CFIA requests personalized ads from ADS. 

5) ADS returned content identifiers for personalized ads. 
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6) CFIA requests MCF(s) to create personalized play lists containing main selected content and ads. Optionally 
trick mode operations can be disabled for ads sat the time of play-list creation. 

7) MCF confirms creation of the play-list. 

8) CFIA returns name of the personalized play-list in the asset URL. 

9) UE initiates unicast session setup. Normal procedure for corresponding service type (e.g. CoD, nPVR) applies. 
Figure 26 presents advertisement "on pause" for unicast based services. 

The procedure is applicable for the following services: 

• Content on Demand. 

• Network PVR. 

• Time Shift TV. 

• Trick Modes on Broadcast TV when the channel is delivered via unicast. 




1 . Content Selection and session setup 



-2. Pause- 
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m4. User Profile 
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-6. Ad Requests 
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Figure 26: *'0n pause*' advertisement for unicast based services. 

1) User selected a content following SD&S procedure discussed in clause 6.3 and starting interactive session. 

2) User paused content session. 

3) Pause triggers MCF to request personalized ad from CFIA. 

4) CFIA optionally requests current user profile in order to request an ad. 

5) UPSF/IUDF returns current profile. 

6) CFIA requests personalized ads from ADS. 

7) ADS returned content identifiers for personalized ads. 

8) CFIA returns to MCF one or more ad identifiers. 

9) MCF instructs MDF to play ads. Ads are being played. 

10) User requests to continue content session. 
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11) Play request triggers MCF/MDF to stop playing ads. 

1 1 .10.3 Advertising procedures using notification 

Same procedures as described in 11.9.1 may be applicable for delivering advertising to UE. 

11.11 Procedures for inter-destination media synchronization 
11.11.1 Mapping 1:SC in UE 

Figure 24 provides an overview of the information flows for inter-destination content synchronization according to 
Mapping 1 from clause 5.3.1.1.2. 



UE 
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1. Sync Initiation Request ( IPTV 
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I 2. Sync Initiation Response 
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Repeat 



4. Calculate sunc 
settings 



-5. Sync Status Instruction- 



1) 



—6. Sync Ternnination Request— 
7. Sync Ternnination Response 

Figure 27: Procedure for inter-destination content synchronization 

The UE (SC) sends a synchronization initiation request to the IPTV Control (MSAS), indicating that it wants 
to participate in the inter-destination synchronization process. The request includes the IPTV content 
identifier, identifying the to-be-synchronized content. The synchronization group identifier (SyncGroupId), in 
combination with the IPTV content identifier, identifies the group of UEs (SCs) that is synchronized as a 
group for the identified IPTV content. 

NOTE 1 : The ways that a UE can obtain a SyncGroupId are similar to obtaining a phone conference id. For 

example, one user can request a new SyncGroupId through an off-line process, and share it with other 
users through an offline process. If the group of users does already have a group identifier, e.g. a phone 
conference id, they may reuse this identifier. 

2) The IPTV Control confirms its participation in the inter-destination synchronization process. 

3) The UE (SC) sends its synchronization status information to the MSAS. 

4) The IPTV Control aggregates synchronization status information from multiple UEs (SCs) and calculates the 
appropriate synchronization settings for each SC. 

NOTE 2: Examples of algorithms to calculate the synchronization settings instructions from collected 
synchronization status information may be found in [i.l]. 

5) The IPTV Control sends a synchronization settings instruction to the UE (SC). 
Steps (3) - (5) may be repeated at regular time intervals. 

6) The UE sends a synchronization termination request, indicating that it is no longer active in the 
inter-destination synchronization process. This could be e.g. because of a channel change by the UE. 
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7) The IPTV Control confirms the termination of its participation in the inter-destination synchronization process. 

NOTE 3: The UE can initiate and terminate multiple synchronization sessions within a broadcast session, both 
consecutive and simultaneous. 

11.11.2 Mapping 2: SC in Transport 

The procedures according to Mapping 2 from clause 5.3.1.1.2 are the same as above with the following changes: 

• Tunnelling over the Ct2 reference point is not applicable. 

• The MS AS is an elementary function of the IPTV Control or a stand-alone Application Server. 

• The SC is an elementary function of the Transport Functions. 

• The request in step (1) includes a media stream identifier. 

• The SyncGroupId may be used to identify multiple synchronization groups, or it may be populated with the 
value "default". 

NOTE 1 : How the SC obtains the SyncGroupId is not described in the present document. 

NOTE 2: If the MS AS serves SCs according to both Mapping 1 and Mapping 2 for a specific IPTV service, then 
the MS AS has to correlate the IPTV content identifier in Mapping 1 , with the appropriate media stream 
identifier in Mapping 2. 

11.12 Service continuation 

This clause discusses procedures for service continuation. 

1 1 .12.1 Procedure for unicast service continuation between NGN IPTV UEs 

Figures 28 and 29 present procedure for unicast based service continuation between NGN IPTV UEs. 
The procedure is applicable for the following services: 

• Trick modes on broadcast TV. 

• Content on Demand. 

• Time-shift TV. 

• Network PVR. 

Service continuation contains two stages - pause and restart. 
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Service Pause Procedure: 
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Figure 28: Unicast based service pause 

1) Content Selection and Unicast Session Setup. Normal procedure for corresponding service type (e.g. CoD, 
nPVR) applies. 

2) Interactive media delivery. 

3) Session transfer decision. 

4) UE optionally puts video session on hold. 

5) UE requests CFIA to put the service on hold passing asset bookmark containing current play time. 

6) CFIA attached asset bookmark to the service profile for later restart. 

7) Session is terminated between UE and MF. Normal session termination procedure for corresponding service 
type (e.g. CoD, nPVR) applies. 

Service Restart Procedure: 



IPTVC 



1 . Request for Service Continuation- 





SD&S and 
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apps 



2. Request 
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Figure 29: Unicast based service restart 

1) UE requests CFIA to restart service (e.g. CoD, nPVR, tsTV session). 

2) CFIA requests user profile foe the available paused assets. 

3) CFIA returns assets available for restart, asset URLs and bookmarks UE. 
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4) UE initiates unicast session setup. Normal procedure for corresponding service type (e.g. CoD, nPVR) applies, 
Content delivery is requested from the paused position. 

1 1 .12.2 Service continuation between fixed NGN between fixed NGN 
Integrated IPTV UE and 3GPP mobile UE 

Figure 30 presents procedure for session continuation between fixed NGN IPTV UE and 3GPP PSS based Streaming 
Service. 
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NOTE: PSS - Packet-switched Streaming Service. 

Figure 30: Procedure for session continuation between TISPAN NGN Integrated IPTV UE 

and IMS based 3GPP mobile UE 

Session Pause: 

1) 3GPP UEl requests CoD offers. 

CoD offers are returned to the UEl. 
UEl sets up video delivery session. 
User decides to restart the video later. 



2) 
3) 
4) 
5) 



UE requests to pause session to be restarted later. 3GPP PSS-SCF passes asset identifier and NPT time offset 
to be included into the user profile. 

6) Session pause is confirmed to the UE. 

7) The UEl releases CoD session. 

8) Session release confirmed to the UEl. 
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Session restart: 

9) IPTV UE2 requests PAUSED assets from CFIA. 

10) CFIA requests the assets from the user profile. 

11) CFIA passes Hst of paused assets to the UE2. 

12) UE2 selects the asset and requests IPTVC to establish a video session. 

13) IPTVC selected MF and informs the UE2. 

14) UE2 requests selected MF to start video delivery from the pause position. 

15) Video is delivered using CoD session. 

11.13 Remote control of IPTV services 

11.13.1 Procedure for Remote Mobile Control of IPTV (Provisioning) 

Figure 31 presents procedures for provisioning aspects for remote control of NGN IPTV services. 
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Figure 31 .A: Binding mobile terminal to IPTV account 

Device binding: 

1) UE (user) requests to bind new mobile device to IPTV account through CFIA. 

2) The CFIA notifies common NGN notifications about binding. 

3) Common NGN ASF (Notifications) asks to the Mobile Service Control Function to acknowledge the binding 

4) The Mobile SCF sends an SMS requesting confirmation from the mobile device being bound. 

5) The remote UE (e.g. mobile) confirms binding. 

6) The Mobile SCF acknowledges to the Common NGN ASF (Notifications). 

7) The Common NGN ASF (Notifications) registers the binding internally, and acknowledges to the CFIA. 

8) End user receives confirmation to IPTV UE. 
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Figure 31. B: Acquisition of content profiles 

Acquisition of content profiles: 

1-2) The CMS updates the external NGN ASF Mobile SCF about CoD Catalogue (e.g. via push operation). 

3-4) The SD&S updates the external NGN ASF Mobile SCF about EPG (e.g. via push operation). 

5-6) The NGN ASF Mobile SCF requests updates about PPV offerings available to the UPSF (e.g. via a pull 
operation). 

1 1 .13.2 Procedure for Remote Mobile Control of IPTV (Operations) 

Figure 32 presents operational aspects for remote control of NGN IPTV services. 




NGN ASF 
IVIobile SCF 




Figure 32. A: IPTV Content Purchase from remote UE 

Content purchase: 

1) Remote UE, e.g. mobile UE, selects content and requests purchase. 

2) If the content is IPTV content, purchased content is reflected in the IPTV user profile. The content purchased 
is available immediately, after the profile update, for playback on the IPTV UE. 

3) IPTV profile update is acknowledged to the Mobile SCF. 

4) Mobile SCF acknowledges successful content purchase to the remote UE. 
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Figure 32.B: cPVR management from remote UE 

Mobile cPVR management: 

1) Mobile UE schedules a recording on the remote IPTV UE. 

The request is passed by Mobile SCF to common NGN ASF (Notifications). 



2) 
3) 

4) 

5) 



The Common NGN ASF (Notifications) targets the appropriate IPTV UE and sends the recording notification. 
The IPTV UE schedules recording operation and reports back to the notification service the acknowledgement. 
In this case, the recording operation will be performed onto the IPTV UE local storage. 

The acknowledgement is reported back to Mobile SCF. 

Mobile SCF acknowledges recording schedule. 



11.14 Personalized Channel 

Personalized Channel (PCh) service allows user to define and watch one or multiple pre-configured/scheduled content 
items as a single (virtual) channel. Personalized Channel information is stored in the user service profile (PCh 
information). 
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Figure 33: Overview of PCh service procedures 
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1) User selects and purchases content for PhC, e.g. from the offers provided by SD&S. UE requests Customer 
Facing IPTV AppHcations to setup PCh service. 

2) CFIA checks service access authorization with UPSF/IUDF. 

3) User defines and configures personalized channel with one or more content items discovered via SD&S, 

e.g. define name for the channel, items on the channel, order, time when each item should be played. Channel 
definition is confirmed to the UE. 

4) Optionally, PCh event (e.g. start of the channel or playout of the new scheduled content item) may trigger 
CFIA notification to the UE, e.g. via notification. 

5) CFIA initiates PCh service towards IPTV-C based on service logic, PCh schedule and user availability to 
watch personalized channel. 

6) IPTV-C reserves required resources. 

7) IPTV-C notifies MCE to start delivery of the personalized content from MDF. 

8) MDF delivers the content to UE on Xd interface. 

NOTE: Content could be controlled as for any CoD service via Xc reference point. 

9) PCh can be terminated either by MCE or UE. MCE may terminate PCh when all the content on the channel has 
been delivered to the UE, or when the channel or user subscription has expired. 

11.15 Time Shift TV 

The Time Shift TV (tsTV) service allows user to view a programme content that has already been broadcasted. In order 
to enable tsTV IPTV SP needs to record a programme/content in the MDF. IPTV SP may limit BC content available for 
tsTV. 

Timeshift TV service is similar to nPVR. However, it is not necessary for the user (e.g. IPTV UE) to indicate in 
advance content be recorded. tsTV content is automatically recorded by the MDF. 

Timeshift TV may have expiration time for tsTV assets. The expiration time is typically different between tsTV and 
nPVR assets (tsTV expiration being commonly shorter, e.g. days weeks vs. months to nPVR). 

During tsTV service, if a program has not been finished, the UE may catch up with the live broadcasted programme 
(similar to Media broadcast with trick modes discussed in clause 1 1.3). 

In order to provide time-shift TV service, MDF records allowed TV programs available on the selected broadcast 
channels. The Time shifted TV programs is later selected by UE from EPG (BCG) via SD&S as discussed in 
clause 6.3.2. The user selects time shift content from the information provided by the SD&S similarly to other CoD 
content. Consequently, initiation and termination of time- shift service should follow CoD procedures described in 
clause 11.2. 

11.16 PVR service 

This clause describes PVR service. In order to provide PVR service, the UE initially selects content from SD&S 
(EPG/BCG) and requests recording via customer facing IPTV application. Content is recorded in the MDF for nPVR or 
directly in the UE for cPVR. 

NOTE: A specific type of cPVR service can be identified - local PVR. The difference between client PVR and 
local PVR is the use of IPTV service control functions for recording management, e.g. IPTV CFIA may 
send notifications regarding the recording of specific content to UE, which then acts upon it for cPVR. 
Optionally network resources can be allocated following specified procedures, e.g. for broadcast TV. 

For the local PVR the recording is controlled by the UE independently of IPTV service control functions. The UE 
manages recording based on local or external EPG information. 

After the recording has been initiated, UE may request either from CFIA (or from local storage) a list of scheduled and 
recorded content. 
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nPVR can support both coupled and decoupled mode. 



In the coupled mode, client is allocated precise disk quota on a selected MDF. The MCF associated with the MDF is 
always selected for interactive control over nPVR services. 

In decoupled mode of nPVR service, statistical optimizations are possible, e.g. only one or small number of content 
copies may be created and users are redirected to the nearest copies via Ct2 interface. 

The nPVR service initiation or content delivery's procedures shall comply with CoD or time-shift TV procedures 
defined in clause 1 1.2. 

An MDF can only provides to the UE recordings of nPVR programs available (scheduled and recorded) from the same 
MDF. 



11.17 Emergency alert 



As discussed in the service level requirements [1], the IPTV architecture shall enable delivery of emergency alert 
notifications based on different aspects, e.g. type of emergency situation, priority, and locality. IPTV integrated 
subsystems may also required secure mechanisms to acquire, verify and inject alert content, e.g. alert message or 
emergency live transmission, after verification of the source. 

The emergency alerts shall immediately and with minimum delay be delivered to the UE. An interruption of active 
content may be required: 

• There are three basic procedures for delivering emergency alert to UE: Using dedicated broadcast channel for 
emergency alert delivery. The UE shall receive the emergency channel for the duration and in parallel to other 
IPTV service. The delivery mechanism shall comply with linear TV procedure described in Clause 11.1. The 
notification message format shall comply with the notification schema defined in clause A.4 [14]. 

• Using notification procedure for message delivery with delivery confirmation. The notification shall follow 
procedure defined in clause 11.8.2. The notification message format shall comply with the notification schema 
defined in clause A.4 [14]. 

• Using advertising procedure for stream insertion or replacement of currently watched content. The procedure 
for including emergency content shall follow generic advertisement procedure defined in clause 11.10 for 
delivery live emergency transmission. 

NOTE: Emergency alert capability can be subject to local or regional regulation. 

11.18 Content Bookmark 

An IPTV Content Bookmark service consists of two main steps: 

• creation of IPTV Content Bookmark: allows a user to create and store configurable pointers to content, 
e.g. entire or parts of content (favourite scene) to be able to quickly access the content 

• retrieving of IPTV Content Bookmark: allows to exchange and share IPTV favourite data. 

Figure 33 provides an overview of IPTV Content Bookmark creation and retrieval. This procedure is applicable at any 
time during IPTV session (e.g. during BC, CoD, nPVR session) or at the SD&S stage (e.g. EPG browsing). 
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Figure 34: Creation, storage and retrieval of IPTV Content Bookmark 

1) The UE requests CFIA to create Content Bookmark and optionally supplies additional data (e.g. description). 
The bookmark data may include content information. 

2) The CFIA may check user profile prior to creating content bookmark. CFIA creates bookmark and generates a 
unique content bookmark ID. Content Bookmark may be stored in user profile. 

3) The CFIA may inform SD&S about the Content Bookmark creation and update SD&S metadata. 

4) The CFIA confirms creation and successful storage of Content Bookmark data. 

5) The UE sends to CFIA request for retrieval Content Bookmark. 

6) The CFIA requests Content Bookmark and generate response including content identification, pointer to the 
bookmarked position, additional metadata. The information should be sufficient to initiate content delivery 
from the bookmarked position. 

7) The CFIA send content bookmark to UE. 



11.19 Interactive TV procedures 



Personalized interactive IPTV services and interworking with external ASFs (as discussed in annex A), e.g. with 
external application, is supported via: 

1) Common NGN ASF, for interactions between IPTV and: 

other NGN services as defined in [1]; 

other TISPAN service level subsystems, e.g. IMS; 

other non TISPAN services, such as Internet. 

2) OS A/Parlay/Parlay X SCS, for interactions between IPTV and Parlay services. 



ETSI 



66 



ETSI TS 182 028 V3.3.1 (2009-10) 



Any defined IPTV service may be part of interactive personalized TV service (e.g. in combination with presence, 
messaging). Interactive TV service may be a combination of existing TV service and external application. High level 
procedure, which is applicable to: 

Interactive TV (e.g. interactive advertising, shows). 

Games. 

Pictures. 

Educational services (quiz, tests). 

Voting. 

TV shopping. 

Chatting. 

Maps. 

Community and Social network services. 

Internet widgets (e.g. via RSS feed for informational portals with weather, news, horoscopes, stock 
information, etc.) 

is presented in figure 35. 
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Figure 35: Personalized Interactive TV applications 

1) UE discovers interactive IPTV application via SD&S and request service initiation from CFIA. 

2) CFIA optionally checks user profile, requests authorization and information for service personalization. 

3) CFIA requests Common NGN ASF to setup interactions with external ASFs, if external ASFs are used. 

4) CFIA replies to the UE optionally attaching information for initiating and using interactive TV service. 

5) UE initiates personalized interactive IPTV service, e.g. interacting with application or with other users. 

6) UE requests termination of Interactive IPTV application. CFIA releases all resources allocated for the 
interactive TV applications. 
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Annex A (informative): 

Interactions between other TISPAN services and IPTV 

services 

This approach assumes that service interaction are based on a dedicated Application Server Function (called common 
ASF) that may explicitly implement the blended service functionality (e.g. pausing the TV on incoming call, e-mail 
notifications, incoming call notifications). Such an ASF can be seen as an NGN Application with respect to the 
TISPAN IPTV architecture. As shown on figure A.l. 

Common NGN ASF provides interactions between IPTV: 

• other NGN services as defined in [1]; 

• other non TISPAN services, such as Internet; 

• with other TISPAN service level subsystems, e.g. between IPTV and IMS. 

A common ASF can be used for delivering customized notifications from multiple service domains (notification 
sources), e.g. IMS-IM, IMS call alert, emergency notification, SMS message, e-mail alert, RSS feed, other to IPTV UE. 
The notifications could be delivered to the UE based on user profile, location, presence and may require response from 
the UE as shown on figure A. 1 . 

A common ASF can be used for presence, e.g. presence server as discussed in annex C. 
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Figure A.1 : Interactions between IPTV and other NGN applications and services 

NOTE: Such interactions are based upon existing interfaces. 

A.1 Interactions based on an OSA/Parlay/Parlay X SCS 

This approach is based an OSA/Parlay/Parlay X Service Capability Server (SCS), that provisions standardized 
interfaces and APIs to external and third party application servers. The use of such an SCS is described in 
ES 204 915 [i.2] and ES 202 504 [i.3]. 
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The OSA SCS acts as a secure gateway between the underlying network and the application with the OSA architecture, 
e.g. it is responsible for providing specific service abilities to third party applications. An SCS further serves to make an 
abstraction of the functionality offered by the network, in effect offering the service capability features of the 
underlying network to the third party applications. 

Figure A.2 shows a simplified version of NGN integrated IPTV architecture, with interfaces to an SCS and subsequent 
external applications. 
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Figure A.2: Interaction between TISPAN Integrated IPTV and an OSA/Parlay/Parlay X SCS 
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Annex B (informative): 

Interaction procedure between IPTV and other service level 

subsystems 

This clause provides interaction procedure between IPTV and other service level subsystems, e.g. IMS, for composite 
services. The flow assumes that users are registered in IMS subsystem. 

The procedure describes multimedia and communication features in converged NGN IPTV applications: caller ID on 
the TV screen User 1 calls User 2 and both are in IMS domain. User 2 is subscribed to a converged IPTV 
service - caller ID notification with options to accept, forward or reject incoming call when another IPTV service is 
active via the IPTV UE. 

The clause presents generic functional steps and does not mandate placement of functions. DRM functions are not 
included. 



IPTV 

UE 

User 2 



IPTV 
lUDF 



IPTV 
ASF 



1. Origiikating c all from User 1 to U^er 

2. S -C51CE accesses User 1 profile 

3. Call i ivitation is deliverdd to 

4. Check IPTV 
.5. Optional reques t 



6. Optional return 



7. 



11. Call 



NGN 
UDAF 



is delivere d to common NG N ASF 



pr ofile. IPT V presence 



9. Deliver call lim; 

2 acce] 
accepted 



10. Usg i 2 accepted 



NGN 
ASF 



oflPTM 
of IPTV 



profile dpta (if n 
] profile data 



ID to the 
the call 

► 



12. S -CSCE can forward EsFVITE to 



UPSF 

User 

profile 




UE 



IMS 
SCSCF 



User: 



IMS 
UE 



IMS 
UE 



ot readily c vailable) 



lome UE 




Figure B.1: High level interactions procedure between IPTV and 
other service level subsystems - IMS/IPTV inter-working 

1) User 1 initiates a call to user 2 from his IMS device UEl. After traversing through the IMS CSCF chain 
invitation (e.g. SIP INVITE) is deHvered to the S-CSCF for User 2. 

2) S-CSCF access user profile data. Dotted arrows indicate that IMS user profile has been requested from UPSF. 

3) S-CSCF, based upon IMS user profile, sends the invitation on ISC interface to common NGN ASF-. The NGN 
ASF is an Application Server Function. Optimizations are possible, e.g. a timer in S-CSCF can automatically 
deliver call upon no response. 

4) NGN ASF checks IPTV user profile: 

a) either by requesting IPTV sub-profile of federalized user profile from NGN lUDF; 

b) or directly from IPTV subsystem from lUDF. 
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5) NGN lUDF optionally request lUDF for IPTV profile. 

6) lUDF returns requested information. 

7) IPTV user profile information is returned to NGN ASF. 

8) NGN ASF, based on IPTV user profile and presence, delivers incoming call notification either to the IPTV 
ASF (Customer facing IPTV application) or directly to the IPTV UE. In the first case steps 9) and 10) are 
optional. Common NGN ASF and other ASF can be located separately, co-located or can be deployed as 
application package. They are shown separately to cover generic case. 

9) IPTV ASF invokes IPTV apphcation to show call line ID to IPTV UE2. 

10) User 2 from IPTV UE chooses to answer the call on IMS UE. 

11) IPTV ASF (or IPTV UE) notifies NGN ASF that the call setup can be continued. 

12) NGN ASF returns invitation to S-CSCF to be deHvered to User 2 IMS home device. 

13) S-CSCF delivers invitation to User 2 IMS home device. 
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Annex C (informative): 
Presence attributes for IPTV 

IPTV services may be combined with the presence service capabiHty. 
The following specific IPTV attributes are supported: 

• Broadcast TV with or without trick modes service activated. 

• CoD service activated. 

• PVR service activated. 

• Near CoD (nCoD). 

• Interactive TV service activated. 

The following specific IPTV attributes may also be supported: 

• Service currently accessed. 

• Content currently accessed. 

• Presence filtering for buddy list members. 

• Buddy list management. 

It is up to user's decision to include specific IPTV attributes in Presence document. 

Service level requirements [1] require that IPTV solution should be able to access and provide presence information. It 
is outside the current release to evaluate whether there is sufficient access to the presence service (i.e. the attribute 
described) for integrated IPTV subsystem. 
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Annex D (informative): 

Possible evolution path for NGN Integrated IPTV 

This annex considers possible migration scenarios from existing solutions (i.e. DVB-IPI, ATIS-IIF) or between NGN 
based IPTV architectures. 



D.1 Evolution of IPTV architectures towards NGN 

For evolution considerations, each evolutional step provides additional functionality and features for additional 
values IPTV services. For example, it could be the Quality of Experience (QoE) for the end users, convergence TV with 
other telecommunications features and interactive multimedia services. An efficient introduction of new services and 
reduction of the operating costs may be another important motivation to evolve the IPTV systems (as shown in 
figure D.l). 



NGN Converged IPTV 

Combination of NGN- Integrated and IMS-based 

IPTV 

in a single architectural framework 



NGN IMS based IPTV 

Introduces interfaces to NASS, RAGS 

and user profile. 

IPTV service ocntrol is based on IP 

Multimedia Subsystem, 
integration into TISPAN NGN via IMS 



NGN Integrated IPTV 

Introduces interfaces to NASS, RAGS 

and user profile. 

Evolution of NGN dedicated IPTV, 

integration into TISPAN NGN, 
interworking & integration with IMS 



Non-NGN IPTV 

IPTV solutions including applicatiuons., service conmtrol and 
media delivery with integration with NGN 



Figure D.1 : The potential IPTV evolution paths for NGN based IPTV architectures 

In comparison with proprietary Non-NGN IPTV solutions, NGN integrated IPTV can provide standardized IPTV 
services and features with standardized IPTV control and media delivery functions. 

NGN based IPTV in both cases enables the integration with User Profile Server Function (UPSF), Network Attachment 
Subsystem (NASS), Resource and Admission Control Subsystem (RAGS) to realize personalized value-added IPTV 
features and to use network resources more efficiently. 

Evolution towards NGN IMS based IPTV is based on the observation that IMS may be used as a unified service control 
platform for some of the NGN services, consequently it can be used for IPTV control. 

NGN based IPTV can either be based on IMS (IMS based IPTV) or interwork with IMS (NGN integrated IPTV). 

However, we cannot expect that all NGN services in the future will be only IMS based. Therefore convergence, 
combination or interaction of IMS with IPTV features can lead to NGN converged IPTV, which can be foreseen in the 
future as common architecture framework (NGN converged IPTV) for coexistence between NGN Integrated IPTV, IMS 
based IPTV and new NGN services and subsystems. 
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D.2 Possible migration and switch over scenarios 

This informative annex discusses migration scenarios from and to NGN integrated IPTV. 

Table D.2: Migration and switch over scenarios 



Evolution step 


UE 


Transport |MC&DF 


Service control Application 


Non-NGN 


STB 


Content delivery network 


IPTV middleware 


TISPAN NGN 
integrated IPTV 


UE 


Transport 
processing, MASS 
&RACS 


MCF&MDF 


IPTV-C/AS Interaction 
with IMS and other NGN 
subsystems 


CFIA, SD&S 


TISPAN IMS based 
IPTV 


UE 


Transport 
processing, MASS 
&RACS 


MCF&MDF 


IMS 


SCF, SSF, SDF 


NGN Converged 
IPTV architecture 


UE 


Transport 
processing, MASS 
&RACS 


MCF&MDF 


This part is for future study in TISPAN NGN 
IPTV architectures 
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Annex E (informative): 
IVIapping of elementary functions 

E.1 IVIapping between elementary functions and generic 
capabilities 

Table E.l presents mapping between elementary functions identified in clause 5.4 and generic capabilities identified in 
clause 5.3. 
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Elementary function 


Discovery & 
selection 


Service 
control 


Service 
interact 


Media 
control 


Deliver 
media 


Content 
protection 


Service 
Protection 


Content mng. & 
distribution 


Service 
interaction 


1 


network attachment 




X 
















2 


registration 




X 
















3 


resource management 




X 
















4 


charging information 




X 
















5 


service discovery 


X 


















6 


service authorization 




X 


X 








X 






7 


service selection 


X 












X 




X 


8 


service initiation 




X 


X 








X 






9 


service control 




X 


X 








X 




X 


10 


service information handling 


X 


X 


X 












X 


11 


service configuration 




X 
















12 


session initiation 




X 


X 








X 






13 


session modification 




X 


X 








X 






14 


session termination 




X 


X 








X 






15 


multicast based media delivery 










X 










16 


unicast based media delivery 










X 










17 


content download/upload 










X 










18 


control of multicast streaming 




X 




X 












19 


control of unicast streaming 






X 


X 












20 


control of download/ upload 




















21 


content ingestion/receiving 










X 






X 




22 


content recording 








X 












23 


content storage 








X 












24 


content adaptation 










X 










25 


content acquisition 
















X 




26 


content validation 
















X 




27 


content distribution 
















X 




28 


content licensing 












X 








29 


key management 












X 


X 






30 


content encryption 












X 








31 


user profile/data mng. 


















X 


32 


accounting/right control 




X 














X 


33 


status/state (changes) detection/reporting 




X 


X 




X 








X 


34 


common notification 




X 


X 












X 


35 


messaging 






X 












X 


36 


presence 






X 












X 


37 


inter-destination media synchronization 






X 




X 








X 


38 


Media and data confidentiality/Integrity 














X 
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E.2 Mapping between elementary functions and 
functional entities 

Table E.2 presents mapping between elementary functions identified in clause 5.4 and functional entities identified in 
clause 5.2. 

Table E.2. Mapping of elementary functions to functional entities 





Elementary function 


UE 


SD&S 


CFIA 


IPTV-C 


lUDF 


UPSF 


MCF 


MDF 


1 


network attachment 


X 
















2 


registration 


X 






X 


X 








3 


resource management 








X 






X 




4 


charging information 








X 








X 


5 


service discovery 




X 














6 


service authorization 








X 










7 


service selection 


X 


X 














8 


service initiation 


X 




X 












9 


service control 


X 






X 






X 




10 


service information handling 


X 


X 














11 


service configuration 


X 




X 












12 


session initiation 


















13 


session modification 


















14 


session termination 


















15 


multicast based media delivery 
















X 


16 


unicast based media delivery 


X 














X 


17 


content download/ 
upload 


X 














X 


18 


control of multicast streaming 


X 












X 




19 


control of unicast streaming 


X 












X 




20 


control of download/ upload 


X 












X 




21 


content ingestion/receiving 


X 














X 


22 


content recording 


X 














X 


23 


content storage 


X 














X 


24 


content adaptation 
















X 


25 


content acquisition 


















26 


content validation 


















27 


content distribution 


















28 


content licensing 


















29 


key management 


















30 


content encryption 
















X 


31 


user profile/data mng. 


X 








X 


X 






32 


accounting/right control 








X 


X 


X 






33 


status/state (changes) detection/reporting 


X 




X 


X 






X 


X 


34 


common notification 


X 




X 












35 


messaging 


X 




X 












36 


presence 


X 




X 












37 


inter-destination media synchronization 


X 




X 
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E.3 Mapping between elementary functions and IPTV services 

Table E.3 presents mapping between elementary functions identified in clause 5.4 and IPTV services as defined in [1]. 

Table 3: Mapping between elementary functions and IPTV services [1]. 





Elementary function 


BC 


CoD 


nPVR 


cPVR 


BCwTP 


UGC 


Push 
CoD 


Adv 


CRS 


Notif 


Msg 


Presence 


1 


network attachment 


X 


X 


X 


X 


X 


X 


X 


X 


X 


X 


X 


X 


2 


registration 


X 


X 


X 


X 


X 


X 


X 


X 


X 


X 


X 


X 


3 


resource management 


X 


X 


X 




X 


X 


X 


X 










4 


charging information 


X 


X 








X 


X 








X 




5 


service discovery 


X 




X 






X 














6 


service authorization 


X 


X 


X 


X 


X 


X 


X 


X 


X 


X 


X 


X 


7 


service selection 


X 




X 


X 


X 


X 


X 












8 


service initiation 


X 


X 


X 


X 


X 


X 


X 


X 


X 


X 


X 


X 


9 


service control 


X 


X 


X 


X 


X 


X 


X 


X 


X 


X 


X 


X 


10 


service information handling 












X 






X 








11 


service configuration 


X 


X 


X 


X 


X 


X 


X 


X 


X 


X 


X 


X 


12 


session initiation 


X 


X 


X 








X 












13 


session modification 


X 


X 


X 




X 


X 


X 












14 


session termination 


X 


X 


X 


X 


X 


X 


X 


X 


X 








15 


multicast based media 
delivery 


X 








X 






X 




X 






16 


unicast based media delivery 




X 


X 




X 


X 




X 




X 






17 


content download/ 
upload 












X 


X 


X 










18 


control of multicast streaming 


X 


X 


X 


X 


X 


X 


X 












19 


control of unicast streaming 


X 


X 


X 


X 


X 


X 


X 












20 


control of download/ upload 


X 


X 


X 


X 


X 


X 


X 












21 


content ingestion/receiving 


X 


X 


X 


X 


X 


X 


X 












22 


content recording 






X 


X 


X 
















23 


content storage 




X 


X 


X 




X 




X 










24 


content adaptation 


X 


X 












X 










25 


content acquisition 


X 


X 






X 


X 


X 


X 










26 


content validation 


X 


X 






X 


X 


X 












27 


content distribution 


X 


X 






X 


X 


X 


X 










28 


content licensing 


X 


X 






X 


X 


X 












29 


key management 


X 


X 






X 


X 


X 












30 


content encryption 


X 


X 






X 


X 


X 












31 


user profile/data mng. 
















X 


X 






X 


32 


accounting/right control 


X 


X 


X 


X 


X 


X 


X 






X 


X 
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Elementary function 


BC 


CoD 


nPVR 


cPVR 


BCwTP 


UGC 


Push 
CoD 


Adv 


CRS 


Notif 


Msg 


Presence 


33 


status/state (changes) 
detection/reporting 




X 


X 




X 


X 


X 


X 


X 


X 




X 


34 


common notification 
















X 


X 


X 






35 


messaging 


















X 




X 




36 


presence 


















X 






X 


37 


inter-destination media 
synchronization 


X 


X 






X 


X 




X 
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Annex F (informative): 

NGN integrated IPTV mapping to other IPTV architectures 

NGN Integrated IPTV subsystem architecture supports IPTV service level requirements defined in [1] and provides 
integration of new or existing IPTV solutions (such as those defined by DVB, ATIS IIF, ITU etc) into the TISPAN 
NGN architecture. 

This annex describes mapping of other IPTV architectures to NGN Integrated IPTV architecture. 



F.1 IVIapping between NGN integrated IPTV subsystem 
and ITU-T non-IMS IPTV architecture 

Comparing ITU-T IPTV architecture [i.lO] with ETSI TISPAN NGN integrated IPTV (the present document) the 
following mapping of functional entities can be identified: 

Table F.1 : Mapping between ITU-T non-IMS IPTV functions 
and TISPAN NGN Integrated IPTV functional entities 



ITU-T non-IMS NGN IPTV 


[i.10] 


TISPAN NGN Integrated IPTV 


IPTV Application Functions 


9.2.1 


Customer Facing IPTV Application FE (CFIA), Service 
Discovery and Selection (SD&S)* (in part) 


IPTV Service Control Functional Block 


9.3.1 


IPTV Control (IPTV-C) 


Service User Profile Functional Block 


9.3.2 


User Data Function (UPSF) 


Content Distribution & Location Control 
Functions 


9.4.1 


Media Control Function (MCF) 


Content Delivery & Storage Functions 


9.4.2 


Media Delivery Function (MDF) 


Content Preparation Functions 


9.2.3 


Content acquisition & preparation functions 


Application Profile Functional Block 


9.2.2 


IPTV User Data FE (lUDF) 


Service & content protection 




Service & Content Protection (SCP) 



NOTE: The in ITU-T non-IMS NGN IPTV application functions enable to UE select and purchase content as 

well as provide content metadata and other information which are in TISPAN Integrated IPTV functions 
of Service Discovery & Selection function. 

Figure F.1 illustrate mapping between functional entities discussed in table F.1. 
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Figure F.1 : Mappings of ITU-T non-IMS functional architecture to TISPAN NGN integrated IPTV 
(ITU-T Recommendation Y.1910 [i.10], figure 10-2: NGN non-IMS IPTV architecture) 
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Annex G (informative): 

Interconnection IVIodels supporting IVIobility Capabilities 

TISPAN NGN integrated IPTV subsystem consider in the future releases the following scenarios for roaming and 
interconnection to the home network: 

1) remote data access to IPTV/content provider; 

2) visited - home network roaming between IPTV providers (served only from home network); 

3) visited - home network roaming between IPTV providers (served form home or visited network); 

4) interconnect between NGN integrated IPTV and IMS based IPTV. 

Scenario A: Remote IPTV user access to home IPTV SP via remote data connection 

The remote IPTV UE can access home IPTV SP via remote IP connection (e.g. via VPN or secure remote access). The 
control signalling and media delivery can reach directly Home Network IPTV SP. However, remote IP connection goes 
via third party IP network relying on the functionality provided by the transport control layer and without agreement 
between home and visited networks the QoS cannot be ensured. 

NOTE: This scenario is outside the scope of TISPAN for current release. 

Scenario B: IPTV roaming by IPTV SP in the Home Network via IPTV SP in the Visited Network (home 
services) 

In this scenario, IPTV platform is available in the Visited Network. However, it proxies service request to the IPTV SP 
in the home network and the content and services are delivered only from Home Network. In this scenario, the delivery 
of the content, metadata, service discovery, selection, service initiation, modification and termination is done from 
home network. It may be required from Home Network IPTV SP to provide transcoding and content adaptation to adapt 
media to parameters required for entering the Visited Network (alternatively this could be done at the edge of visited 
network). 

Scenario C: IPTV roaming by IPTV SP in the Visited Network with IPTV SP in the Home Network (home and 
visited services) 

As scenario B, but IPTV SP in the visited network only request content form the home network if it is not available in 
the visited network. 

Scenario D: IPTV roaming by IMS based IPTV SP in the visited network 

Scenarios B and C applied to the case when IPTV SP in the visited network is based on IMS. 
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Annex H (informative): 

SCTE based targeted advertising architecture 



H.1 Definitions 



The SCTE has defined the following advertisement system functional entities [i.6] and [i.7]: 

• Ad Decision Service (ADS): The Ad Decision Service determines how advertising content is combined with 
non-advertising (i.e. entertainment) content assets. The decisions made by an ADS may be straightforward 
(i.e. specific ad content placed at a specific time in a specific asset) or arbitrarily complex (based on subscriber 
data, advertising zone, etc.). 

• Ad Management Service (ADM): The Ad Management Service communicates placement opportunity and 
placement status to the ADS. The message interfaces exposed by an ADM allow for both preconfigured ad 
decisions as well as real-time fulfilment models. Possible ways for detection of a placement opportunity are 
discussed in clause 1 1.10. In addition, the ADM may be a service consumer of a POIS and/or a CIS in order to 
obtain such information. 

• Content Information Service (CIS): The Content Information Service manages metadata describing all the 
assets (both advertising assets and non-advertising assets) available to the other SCTE 130 logical services. 
The CIS provides query and notification interfaces to the other logical services. 

• Placement Opportunity Information Service (POIS): The Placement Opportunity Information Service 
(POIS) holds, maintains, or retains descriptions of placement opportunities. 

• Subscriber Information Service (SIS): The Subscriber Information Service manages the per-subscriber 
information relevant to ad placement decisions. The SIS provides mechanisms surrounding privacy issues. 



H.2 SCTE-1 30 based Advertising Architecture 

Figure H.l shows the interfaces between the SCTE- 130 advertising specific entities and the TISPAN IPTV architecture. 
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Figure H.1: Interaction between TISPAN Integrated IPTV architecture 
and SCTE-130 functional entities 
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The IPTV applications are interconnected with the ADS by the ADx reference points to request ad placement decision. 
The ADM functionality in MF is interconnected with the Ad Decision Service by the ADy reference points to request 
ad placement decision. As shown on figure H.l, POIS is an external entity. However, ad placement opportunities may 
be detected by the MF based on cues defined in [i.8]. SIS may be either exposed by lUDF or user Data. ADM located in 
CFIA, MF and optionally UE can coexist and are not mutually exclusive. 



H.3 Reference points 

H.3.1 IPTV Applications - SCTE-130 ADS (ADx) 

This reference point is used to exchange advertising related messages between an ADM in the CFIA and an SCTE-130 
Advertising sub-system. ADx reference point should be used to send and receive messages from/to the ADS, POIS and 
SIS entities and the TISPAN IPTV AppHcations. 

The use of ADx between SCF and ADS conforms to SCTE 130-3 [i.7]. It may be a subset of SCTE 130-3 [i.7] depending 
on the functionality supported in the CFIA and ADS and that is declared during the discovery and registration phases. 

H.3.2 IPTV Media Function (MF) - SCTE-1 30 ADS (ADy) 

This reference point is used to exchange advertising related messages between MF and an SCTE-130 ADS for unicast 
and broadcast services. ADy reference point should be used to send and receive messages from/to the ADS and the 
TISPAN IPTV MF. It may be a subset of SCTE 130-3 depending on the functionality supported in the MF and ADS 
and that is declared during the discovery and registration phases. 
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The MF entity is interconnected with the Ad Decision service by the ADy reference point to made ad-selection and ad- 
placement requests for both broadcast and unicast (e.g. for interstitial, pause opportunities) services. 

The use of ADy between MCF and ADS conforms to SCTE130-3 [i.7]. It may be a subset of SCTE130-3 [i.7] 
depending on the functionality supported in the MF and ADS and that is declared during the discovery and registration 
phases. 

H.3.3 MF Ad Splicer - TISPAN Ad MF (ADc) 

This reference point is used to exchange ad streaming related messages in order to control streaming of ads by the ad 
splicer from Ad MF. 

The use of ADc between MF ad spHcer and TISPAN Ad MF conforms to SCTE-130. 

H.3.4 IPTV User Equipment (UE) - SCTE-1 30 ADS (ADz) 

This optional reference point is used to exchange advertising related messages between UE and an SCTE-130 external 
Advertising sub-system. ADz reference point should be used to send and receive messages from/to the ADS and the 
TISPAN UE. The UE entity is interconnected with the Ad Decision service by the ADz reference point to made 
ad-selection and ad-placement requests. 

The use of ADz between UE and ADS conforms to a relevant subset of SCTE 130-3 [i.7]. It may be a subset of 
depending on the functionality supported in the ADS and UE and that is declared during the discovery and registration 
phases. 



H.4 Mapping between TISPAN entities and SCTE-1 30 
entities 

This clause describes a mapping of the functional entities defined by SCTE with the TISPAN IPTV functional entities. 

Placement Opportunity Information Service (POIS) and Ad Decision Service (ADS) are considered out of scope of 
TISPAN architecture. Interface between ADS and ADM is considered as a reference point in scope of TISPAN. 

Table H.l describes mapping between TISPAN IPTV functional entities and SCTE functional entities. 

Table H.1 : Mapping between TISPAN IPTV functional entities and SCTE functional entities 



SCTE-130 entity 
name 


Role 


TISPAN Entity 


TISPAN entity role 


POIS 


Provides placement opportunities 


MF / External entity 


MF tasks from clause 11.10.1 
"When MF performs ad insertion, it is 
informed or determines of ad insertion 
opportunity, retrieves ad content and 
delivers the combined stream to the 
UE." 


SIS 


IVIanage subscriber information 
relevant for Ad 


lUDF/ User Data/ 
External entity 


lUDF/User Data role is defined in 
clause 5.1.1. 


CIS 


Manage assets metadata 


SD&S/ Media 
Preparation 
(Acquisition) / External 
entity 


SD&S role is defined in clause 5.1 .1 . 
Media Preparation role is defined in 
clause 5.1.2. 


ADM 


Provides placement opportunities 

based on POIS and CIS 

information 

Defines messages for Ad 

insertion Activities 


CFIA - applications 
and unicast TAI 
MF - unicast and 
multicast TAI 


CFIA role is defined in clause 1 1 .1 0.2 
and on figure 25. 


ADS 


Decide ad placement relative to 
content based on ADM 
placement opportunities 


NGN ASF 
entity/External entity 


Defined externally [i.5], [i.6] and [i.7]. 
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Annex I (informative): 

NGN integrated IPTV support for hybrid services 

The present document integrates IPTV/TV systems, e.g. defined in [2], into NGN architecture. Some of IPTV 
subsystems and service level requirements [1] may include hybrid services. 

The present document does not preclude using IP delivery for a consumer's complete IPTV service offering or for 
partially combined with other TV services in a hybrid service scenario. For example, a service provider may chose to 
offer broadcast services (e.g. broadcast TV) via an independent channel while providing interactive, download or CoD 
IPTV services via the IP network. 

NGN integrated IPTV may support hybrid delivery of IPTV services, e.g.: 

• Live TV deHvery over external TV delivery systems such as DVB-T, DVB-S, DVB-C, DVB-H, 3GPP 
MBMS, other. 

• Other IPTV services delivered over NGN integrated IPTV such as CoD, UGC, iTV, other as defined above. 

Hybrid approaches can offer advantages both to the service provider and the consumer and widen the application of 
TISPAN NGN Integrated IPTV, e.g. where a part of the IPTV content is delivered over an independent non-IP delivery 
network, such as. terrestrial broadcast, direct-to-home satellite, hybrid fibre-coax or optical distribution network, which 
is outside of scope for TISPAN. 
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